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1.  GENERAL  INFORMATION 


1.1  PURPOSE  OF  THIS  DOCUMENT 


This  dociament  records  working  (not  stable)  implementation 
specification  agreements  of  OSI  protocols  among  the  organizations 
participating  in  the  NIST  Workshop  for  Implementors  of  OSI.  This  work 
is  not  currently  considered  advanced  enough  for  use  in  product 
development  or  procurement  reference.  However,  it  is  intended  that 
this  work  be  a basis  for  future  stable  agreements.  It  is  possible 
that  any  material  contained  in  this  document  may  be  declared  stable  in 
the  future,  and  the  material  should  be  considered  in  this  light.  In 
the  status  sections  of  each  chapter  as  appropriate,  specific 
functionality  may  be  flagged  as  being  "likely"  to  become  stable  at  the 
next  workshop . 

Only  non-stable  text  is  included  in  this  document.  Errata  to  Stable 
material,  as  well  as  new  stable  functionality,  is  presented  as  an 
aligned  edition  (in  replacement  page  format)  issued  at  the  same  time 
as  this  document. 

As  each  protocol  specification  is  completed  (becomes  technically 
stable) , it  is  moved  from  this  working  document  to  the  stable 
companion  document  as  described  below. 

o The  companion  document,  "Stable  Implementation  Agreements  for 
Open  Systems  Interconnection  Protocols,  Version  3,  Edition  2, 
March  1990"  records  mature  agreements  considered  advanced  enough 
for  use  in  product  development  or  procurement  reference. 

New  text  relating  to  any  of  the  referenced  subjects  appears  first  in 
this  working  document.  In  general,  new  text  must  reside  in  this 
working  document  for  at  least  one  workshop  period  before  being  moved 
into  the  Stable  Document,  except  in  rare  instances. 

Agreements  text  is  either  in  this  Working  Document  (not  yet  stable)  or 
in  the  aligned  Stable  Document  (has  been  declared  stable).  It  is  a 
goal  that  the  same  text  not  appear  in  the  same  position  in  both 
documents  at  once  (except  for  section  one) . 

The  benefit  of  this  document  is  that  it  gives  the  reader  a glimpse  of 
new  functionality,  for  planning  purposes.  Together  with  the  aligned, 
associated  stable  document,  these  two  documents  give  the  reader  a 
complete  picture  of  current  OSI  agreements  in  this  forum. 

An  implementor  should  look  at  the  aligned  section  in  the  Stable 
Document  to  get  the  true  current  status  of  stable  material.  In  this 
Working  Document,  all  references  to  the  Stable  Document  are  to  V3 , E2 
(March  1990).  Where  appropriate,  statements  related  to  backward 
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compatibility,  interworking  considerations,  or  agreement  maintenance 
are  given  in  this  document. 


1.2  PURPOSE  OF  THE  WORKSHOP 


At  the  request  of  industry,  the  National  Institute  of  Standards  and 
Technology  organized  the  NIST  Workshop  for  Implementors  of  OSI  to 
bring  together  future  users  and  potential  suppliers  of  OSI  protocols. 
The  Workshop  accepts  as  input  the  specifications  of  emerging  standards 
for  protocols  and  produces  as  output  agreements  on  the  Implementation 
and  testing  particulars  of  these  protocols.  This  process  is  expected 
to  expedite  the  development  of  OSI  protocols  and  promote  inter- 
operability of  independently  manufactured  data  communications 
equipment . 


1.3  WORKSHOP  ORGANIZATION 


See  the  aligned  section  of  the  Stable  Implementation  Agreements 
Document  for  information. 


1.4  USE  AND  ENDORSEMENT  BY  OTHER  ENTERPRISES 


The  Workshops  are  held  for  those  organizations  expressing  an  interest 
in  implementing  or  procuring  OSI  protocols  and  open  systems.  However, 
there  is  no  corporate  commitment  to  implementations  associated  with 
Workshop  participation. 

The  Agreements  in  this  document  were  a basis  for  testing  and  product 
demonstrations  in  the  Enterprise  Networking  Event  in  Baltimore,  MD, 
June,  1988. 

The  agreements  contained  in  earlier  versions  of  this  document  were 
used  for  OSI  demonstrations  at  the  National  Computer  Conference  in 
1984  and  at  the  AUTOFACT  conference  in  1985. 

The  agreements  from  several  versions  of  this  document  have  been 
adopted  for  use  in  implementations  running  on  OSINET. 

The  MAP/TOP  Steering  Committee  has  endorsed  these  agreements  and  will 
"continue  the  use  of  the  most  current,  applicable  Implementors 
Workshop  Agreements  in  all  releases  of  the  MAP  and  TOP 
specifications . " 

The  COS  Strategy  Forum  has  "adopted  a resolution  stating  that  as  a 
matter  of  policy  COS  should  select  as  its  sources  of  Implementation 
Agreements  organizations  or  forums  that  are:  (1)  Broadly  open,  widely 


1-2 


March  1990  (Working) 


recognized  OSI  Workshops  (NIST/OSI  Workshops  are  first  preference) 

It 


The  implementation  specifications  from  the  "Stable  Implementation 
Agreements  for  Open  System  Interconnection  Protocols"  are  referenced 
in  Federal  Information  Processing  Standard  146,  "Government  OSI 
Profile  (GOSIP)." 


1 . 5 RELATIONSHIP  OF  THE  WORKSHOP  TO  THE  NIST  LABORATORIES 


As  resources  permit,  NIST,  with  voluntary  assistance  from  industry, 
develops  formal  protocol  specifications,  reference  implementations, 
tests  and  test  systems  for  the  protocols  agreed  to  in  the  Workshops. 
This  is  work  made  available  to  the  industry  volunteers  and  to  others 
making  valid  commitments  to  organized  events  and  activities  such  as 
NCC , AUTOFACT,  and  OSINET.  As  soon  as  this  work  can  be  adequately 
documented,  it  is  placed  in  the  public  domain  through  submission  to 
the  National  Technical  Information  Service.  Any  organization  may  then 
obtain  the  work  at  nominal  charge. 

The  NIST  laboratories  bear  no  other  relationship  to  the  Workshop. 


1.6  STRUCTURE  AND  OPERATION  OF  THE  WORKSHOP 


1.6.1 Plenary 

The  main  body  of  the  Workshop  is  a plenary  assembly.  Any 
organization  may  participate.  Representation  is  international. 
NIST  prefers  for  the  business  of  Workshops  to  be  conducted 
informally,  since  there  are  no  corresponding  formal  commitments 
within  the  Workshop  by  participants  to  implement  the  decisions 
reached.  The  guidelines  followed  are:  1)  one  vote  per  company 
or  Independent  division,  2)  only  companies  that  regularly  attend 
should  vote,  3)  only  companies  that  plan  to  sell  or  buy  a 
protocol  should  vote  on  its  implementation  decisions,  4)  only 
companies  knowledgeable  of  the  issues  should  vote,  and  5)  no 
proxy  votes  are  admissible.  Other  voting  rules  are  contained  in 
the  draft  Procedures  Manual,  Section  2.3. 


1.6.2 Special  Interest  Groups 

Within  the  Workshop  there  are  Special  Interest  Groups  (SIGs).  The 
SIGs  receive  their  instructions  for  their  technical  program  of 
work  from  the  plenary.  The  SIGs  meet  independently,  usually 
during  the  Workshop.  As  technical  work  is  completed  by  a SIG,  it 
is  presented  to  the  plenary  for  disposition.  Companies 
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participating  in  a SIG  are  expected  to  participate  in  the 
plenary.  Voting  rules  for  SIGS  are  the  same  as  voting  rules  for 
the  plenary. 

Special  Interest  Groups  sometimes  correspond  with  organizations 
performing  related  work,  such  as  ANSI  committees.  Such 
correspondence  should  be  sent  through  the  plenary  to  the  parent 
committee,  such  as  ANSI  X3T5  or  ANSI  X3S3.  When  SIG  meetings 
take  place  between  Workshops,  the  correspondence  from  these 
meetings  should  be  addressed  directly  to  the  parent  committee 
and  copied  to  the  Workshop  plenary. 

Following  are  procedures  for  cooperative  work  among  Special 
Interest  Groups. 

o Any  SIG  (SIG  1)  or  individual  having  issues  to  discuss 
with  or  requirements  of  another  SIG  (SIG  2)  should 
bring  the  matter  to  the  attention  of  the  chairperson  of 
that  SIG  (SIG  2). 

o The  SIG  2 chairperson  should  bring  the  matter  before 
SIG  2 for  action. 

o SIG  2 should  respond  to  the  concerns  or  needs  of  SIG  1 
or  the  individual  in  a timely  manner. 

o If  the  matter  cannot  be  satisfactorily  resolved  or  if 
the  request  is  outside  the  charter  assigned  to  SIG  1, 
then  it  should  be  brought  before  the  plenary. 

o SIGs  are  expected  to  complete  work  in  a timely  manner 
and  bring  the  results  before  the  plenary  for 
disposition.  However,  the  plenary  may  elect  to  act  on 
any  issue  within  the  scope  of  the  workshop  at  any  time. 

Following  are  the  charters  of  the  Special  Interest  Groups. 

FTAM  SIG 

Scope 

o to  develop  stable  FTAM  Agreements  between  vendors  and  users  for 
the  implementation  of  interoperable  products 

o in  particular  to  maintain  the  FTAM  Phase  2 and  Phase  3 

specifications  with  respect  to  experiences  from  implementations 
and  from  testing.  It  is  a goal  that  FTAM  Phase  3 will  remain 
backward  compatible  with  FTAM  Phase  2. 

o to  act  as  Registration  Authority  for  OIW  FTAM  objects. 
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o to  define  further  FTAM  functionality. 

o to  conduct  liaison  with  standardization  bodies  such  as  ISO  SC  21 
and  AITS  I X3T5 . 5 . 

o to  conduct  liaison  with  and  contribute  to  other  bodies  working  on 
FTAM  harmonization  such  as  the  Regional  Workshops  (EWOS,  AOW)  and 
the  ISO  SGFS  to  define  Functional  Standards 

and 

o to  conduct  liaison  with  vendor/user  groups  such  as  COS,  MAP,  TOP, 
and  SPAG 

High  priority  work  items: 

o Maintain  FTAM  Phase  2 and  Phase  3 Agreements 
o Maintain  OIW  FTAM  object  register 
o Contribute  to  development  of  FTAM  ISPs 
o Specify  use  of  general  Character  Set  Agreements 
o Specify  requirements  of  FTAM  to  a Directory  Service 
o Specify  use  of  Filestore  Management  functions 
Low  priority  work  items: 

o Specify  use  of  Security  functions 

o Specify  use  of  Overlapped  Access 

(MESSAGE  HANDLING  SYSTEMS)  SIG 

Develop  and  maintain  product  level  specifications  for  Message  Handling 
Systems  using  the  CCITT  X.400  recommendations  (and  corresponding 
documents).  Review  Abstract  Tests  for  X.400  and  provide  feedback  to  the 
appropriate  bodies. 

LOWER  LA.YER  SIG 


The  Lower  Layer  SIG  will  study  OSI  layers  1-4  and  produce 
recommendations  for  implementations  to  support  the  projects  undertaken  by 
the  workshop  and  the  work  of  the  other  SIGs.  Both  connectionless  and 
connection-oriented  modes  of  operation  will  be  studied.  The  SIG  will 
accept  direction  from  the  plenary  for  work  undertaker,  and  the  priority 
which  it  is  assigned. 

The  objectives  of  the  Lower  Layer  SIG  are: 
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o Study  OSI  layers  1-4  as  directed  by  the  plenary  - such  study  is 
to  include  management  objects,  security,  ISDN  user-network 
interfaces  for  use  in  conjunction  with  OSI  network  services, 
routing  exchange  protocols,  etc. 

o Produce  and  maintain  recommendations  for  implementation  of  these 
layers , 

o Where  necessary,  provide  input  to  the  relevant  standards  bodies 
concerning  layers  1-4,  in  the  proper  manner,  and 

o Review  base  standard  abstract  test  suites  with  the  goal  of 
identifying  the  test  cases  required  for  the  layer  1-4 
Implementation  Agreements,  Develop  test  cases  for  Implementation 
Agreement  functionality  not  present  in  the  base  standard  (if 
any) . 

OSI  SECURITY  ARCHITECTURE  SIG 


GOAL:  To  develop  an  overall  OSI  Security  Architecture  which  is 

consistent  with  the  OSI  reference  model  and  which 
economically  satisfies  the  primary  security  needs  of  both 
the  commercial  and  Government  sectors. 

APPROACH:  To  define  a security  architecture  encompassing  the  security 
addenda  presently  being  specified  at  certain  OSI  layers,  the 
required  cryptographic  algorithms  and  related  key  management 
functions,  and  the  security  management  functions  which  must 
be  performed  between  the  layers  and  the  peer  entities 
defined  in  the  OSI  architecture. 


OBJECTIVES: 

o to  develop  agreements  based  on  IS/DIS 

o to  develop/draft  NWI  proposals  for  submission  to  national 
bodies  on  areas  not  covered  by  existing  standards  work 

o to  draft  contributions  on  proposed  NWIs 

o to  register  security  objects 

o to  provide  consultancy  to  other  SIGs 

o to  act  as  a well-focused  group 

to  propagate  security  information 

to  recommend  and  coordinate  activities. 

DIRECTORY  SERVICES  SIG 
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Produce  functional  implementation  agreements  based  on  ISO/CCITT 
specifications  for  Directory  Services  in  accordance  with  the  objectives 
and  goals  of  the  plenary. 

o Provide  a subset  for  NIST  publication  which  is  functional  and 
forward  compatible  to  further  work  by  this  Special  Interest 
Group . 

o Define  stable  core  functionality  which  can  be  implemented  in  the 
near  term. 

VIRTUAL  TERMINAL  SIG 


This  Special  Interest  Group's  charter  is  based  upon  the  implementation  of 
International  Standards  9040  and  9041  in  providing  Basic  Virtual 
Terminal  Service. 


This  group  will  develop  agreements  for  the  implementation  and  testing  of 
the  following  VTE-prof iles . 


o X.29  PAD 

o TELNET 

o Basic  Scrolling 

o Basic  Paging 

o Basic  Forms 


UPPER  LAYERS  SIG 


The  charter  of  the  Upper  Layers  SIG  is  as  follows. 

o Develop  product  level  specifications  for  the  implementation  of; 
o Session  service  and  protocol 

o Presentation  service  and  protocol 

o ACSE  service  and  protocol 

o Remote  Operations  Service  Element  (ROSE) 

o Reliable  Transfer  Service  Element  (RTSE) 

o In  addition,  the  specifications  to  be  developed  by  the  Upper 

Layers  STG  will  address  issues  that  are  common  to  layers  5-7  such 
as  addressing,  registration,  etc.  This  SIG  will  review  output 
and  proposals  from  other  SIGs  to  ensure  consistency  with 
international  standards  regarding  Upper  Layer  Architecture. 

o The  specifications  developed  will  be  done  to  support  the 
requirements  of  all  ASE  SIGs. 

The  objectives  of  the  Upper  Layers  SIG  are  to: 

o Study  OSI  Session,  Presentation,  ACSE,  ROSE,  and  RTSE 
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o Incorporate  implementor's  agreements  in  the  1988  NBS  standing 
document , 

o Produce  and  maintain  recommendations  for  implementations  of  these 
layers , 

o Where  necessary  provide  input  to  the  relevant  standards  bodies 
concerning  Session,  Presentation,  ACSE,  ROSE,  and  RISE 

o React  in  a timely  manner  (i.e.,  to  develop  corresponding 

implementor's  agreements)  to  technical  changes  in  ISO  documents. 

The  following  are  the  guidelines  under  which  the  Upper  Layers  SIG  will 
operate : 

o Align  implementation  agreements  with  other  organizations  such  as 
ANSI  and  ISO, 

o Develop  implementor's  agreements  that  promote  the  efficiency  of 
protocols , 

o Develop  implementor's  agreements  that  promote  ease  in  the 
verification  of  interoperability, 

o Develop  necessary  conformance  statements. 

NETWORK  MANAGEMENT  SIG 


Will  use  phased  workload  approach  to  accommodate  volume  of  emerging  OSI 
management-related  standards. 

The  SIG  will: 

o Agree  upon  NIST  Implementors  OSI  systems  management  reference 
model 

o Develop  product  level  specifications  for  implementations, 

relating  to  common  services/protocols  for  exchanging  management 
information  between  OSI  nodes 

o Develop  product  level  specifications  for  implementations  relating 
to  specific  management  services  for  exchanging  fault  management 
(FM) , Security  Management  (SM),  Configuration  Management  (CM), 
Accounting  Management  (AM) , and  Performance  Management  (PM) 
information  between  OSI  nodes 

o Initiate  and  coordinate  with  appropriate  layer  SIGs  product  level 
specifications  of  layer-specific  management  information  to 
support  FM,  SM,  CM,  AM,  and  PM. 
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As  necessary,  the  SIG  will: 

o Establish  liaisons  with  various  standards  bodies 

o Provide  feedback  for  additional/enhanced  services  and  protocols 
for  OS I management 

OFFICE  DOCUMENT  ARCHITECTURE 

The  SIG  will: 

o develop  one  or  more  product  level  specifications  for 

implementations  of  ISO/DIS  8613,  i.e.,  the  SIG  will  define  one  or 
more  Document  Application  Profiles  (DAPs) 

o develop  requirements  for  conformance  testing  of  products 
purporting  conformance  to  the  (se)  DAP  (s) 

o specify  and  describe  requirements  for  services  that  manage  the 

generation  and  interpretation  of  the  ODA  document  representation 

o determine  preferred  relationships  between  ODA  and  other  document 
interchange  formats 

o promote  the  SIG's  agreements  (e.g,,  presentations,  product 
demonstrations,  press  releases) 

As  necessary,  the  SIG  will: 

o establish  liaison  with  required  SIGs  (e.g.,  , FTAM,  and  Upper 

Layers  SIGs)  to  seek  efficient  transfer  capability  for  document 
interchange  based  on  the  ODA  SIG  agreements 

o provide  feedback  and  liaison  to  groups  working  on  ISO/DIS  8613 
related  activities 

REGISTRATION  SIG 

The  NIST  OSI  Workshop  Registration  Authority  Special  Interest  Group  (RA 

SIG)  will  deal  with  OSI  Registration  for  the  following  areas: 

A.  Registration  of  NIST  OSI  Workshop-Specified  Objects. 

The  NIST  OSI  Workshop  RAD  SIG  will  define  the  procedures  for  the 

operation  of  the  NIST  Registration  Authority  (i.e.,  NIST). 

1.  Define  policies  and  procedures  for  the  registration  of  objects 
defined  by  the  NIST  OSI  Workshop, 

2.  Take  account  of  currently  existing  OSI  Workshop  registration 
work. 
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3.  Establish  policies  for  the  publication  and  promulgation  of 
registered  objects; 

4.  Liaise  with  other  OSI  Workshop  SIGs,  appropriate  standards  bodies 
(e.g.,  ANSI)  and  other  appropriate  organizations. 

B.  Support  for  ANSI  (U.S.)  Registration  activities 

Promote  the  registration  of  MHS  Private  and  Administrative  Management 
Domain  Names,  Network-Layer-Addresses,  and  other  Administrative  Objects 
by  ANSI  or  a surrogate  appointed  by  ANSI.  If  ANSI  feels  that  it  cannot 
serve  as  the  Registration  Authority  or  delegate  its  authority  to  another 
organization,  then  the  NIST  OSI  Workshop  RA  SIG  should  actively  support 
the  search  for  another  organization  to  carry  out  this  work. 

This  SIG  will  conduct  a self-assessment,  three  NIST  OSI  Workshop  Plenary 
Meetings  after  the  Charter  is  approved,  to  determine  if  it  has  fulfilled 
its  mission.  Based  on  this  assessment,  the  SIG  will  either  be  disbanded 
or  continue.  This  procedure  will  continue  until  the  SIG  is  disbanded. 

TRANSACTION  PROCESSING  SIG 


The  SIG  will  be  the  focal  point  for  all  work  on  Transaction  Processing 
within  the  Workshop.  In  particular; 

1.  Define  DP/DIS/IS  10026  (TP)  Implementation  Agreements. 

2.  Liaise  with  Upper  Layers  SIG  to  define  DIS/IS  9805  (CCR) 
Implementation  Agreements  to  satisfy  TP  requirements. 

3.  Liaise  with  other  internal  and  external  organizations  as 
required. 

tlANUFACTURING  MESSAGE  SPECIFICATION  rMMSl  SIG 

Scope 

To  create  an  open  forum  for  discussion  and  agreements  pertaining  to  MMS 
and  issues  related  to  MMS. 

Obi ectives 

o To  produce  agreements  for  implementations  of  MMS  (ISO  9506) 

o To  produce  implementation  agreements  for  IS  implementations  which 

enable  existing  DIS  based  implementations  (such  as  specified  in 
the  MAP  3.0  specification)  with  minimal  modifications  to 
interoperate  with  IS  implementations. 
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o To  produce  implementation  agreements  on  MMS  Companion  Standards 

(as  recognized  by  ISO  TC184/SC5/WG2)  after  those  have  reached  ISO 
DIS  or  equivalent  status. 

o Develop  Conformance  requirements 

o Develop  recommendations  on  MMS  testing 

As  Necessary 

o Respond  to  defect  reports  as  accepted 

o Provide  feedback  on  Addendtim  material 

o To  produce  implementation  agreements  on  any  ISO  DIS  (or  higher 

level)  or  equivalent  document  defining  alternate  mappings  of  MMS 
to  an  OSI  or  other  international  standards  based  manufacturing 
communications  architecture  such  as  might  be  progressed  from  lEC 
SE  65 

o Provide  input  on  ISP  for  MMS  when  the  ISO  process  for  it  is 
defined 

High  Priority  Work  Items 

o Define  a subset  of  MMS  (ISO-9506)  suitable  for  initial 
implementations 

o Produce  a set  of  implementation  agreements  appropriate  to  that 
initial  subset  of  MMS  encompassing  the  objectives 

o Study  ISO  test  methodologies  and  produce  recommendations  for  MMS 
test  implementations.  If  necessary,  provide  input  on  MMS 
specific  requirements  for  the  ISO  test  methodologies 

o Provide  input  to  ISO  on  Abstract  Test  Cases  to  facilitate 

conformance  and  interoperability  testing  on  the  initial  subset 

o Provide  input  to  ISO  on  the  elaboration  of  service  procedures  for 
error  conditions  and  on  the  relation  of  the  use  of  specific  error 
codes  to  these  error  conditions  for  the  initial  subset. 

Low  Priority  Work  Items 

o Study  and  comment  on  DP  level  or  equivalent  documents  relating  to 
MMS  activities  defined  in  the  objectives 

o Develop  subsequent  subsets  of  MMS 
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o Produce  a set  of  implementors  agreements  for  the  subsequent 
subsets 

o Provide  input  on  Test  Cases  for  the  subsequent  subsets 

o Provide  input  on  errors  for  the  subsequent  subsets 

o Provide  input  to  ISO  on  MMS  ASE  specific  management  entities. 

REMOTE  DATABASE  ACCESS  SIG 


Scope : 

For  all  RDA  Implementations  based  on  ISO  9579: 
o Develop  Implementors'  agreements; 

o Provide  input  to  national  and  international  standards 
organizations  on  RDA  related  standards  and  profiles; 

o Coordinate  with  other  organizations  on  matters  relevant  to  RDA. 

Obi ectives : 

o Use  ISO  9579  Generic  RDA  and  the  ISO  SQL  Specialization  as  a 
basis  for  Implementors'  Agreements  on  the  RDA  SQL  ASE  and  its 
application  contexts; 

o Provide  input  to  ANSI  and  ISO  on  the  specification  of  an  RDA  ISP. 
High  Priority  Work  Items 

1.  To  develop  a work  plan  for  RDA  Implementors'  Agreements  with  an 
associated  time  schedule,  using  the  following  tasks  as  a basis: 

a.  review  ULA  agreements  affecting  RDA  implementations, 

b.  specify  limits  on  encodings  in  RDA  pdus , 

c.  specify  minimum  conformance  requirements  for  RDA 
implementations , 

d.  identify  and  describe  recommended  practices  in  the 
implementation  of  RDA  services  and  protocols , 

e.  identify  implementor  defined  items  in  ISO  9075  (SQL) 
affecting  interoperability  in  an  OSI  environment, 

f.  identify  implementor  defined  items  in  ISO  9579  (RDA) 
affecting  interoperability. 
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g.  identify  RDA  implementation  requirements  for  CCR  and  TP, 

h.  harmonize  ULA  requirements  with  SQL  requirements  with 
respect  to  handling  of  variant  character  sets  in  RDA. 

Low  Priority  Work  Items 

1.  Future  RDA  specializations,  if  any. 
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( 


OS I Workshop  - Chairman 

Tim  Boland 

NIST 

(301) 

975-3608 

OSI  Workshop  - Registration 

Brenda  Gray 

NIST 

(301) 

975-3664 

Directory  Services  SIG 

Chris  Moore 

Touch  Comm. 

(408) 

374-2500 

FTAM  SIG 

Klaus  Truoel 

GMD/DFN 

49-615-] 

L-875-700 

Lower  Layers  SIG 

Fred  Burg 

AT&T 

(201) 

949-0919 

Manufacturing  Message 
Specification  (MMS)  SIG 

Herbert  Falk 

SISCO 

(313) 

774-0070 

Network  Management  SIG 

Paul  Brusil 

Mitre 

(617) 

271-7632 

ODA  SIG 

Frank  Dawson 

IBM 

(214) 

556-5052 

Remote  Database  Access  SIG 

Rich  Gerhardt 

GM 

(313) 

947-0572 

Security  SIG 

James  Galvin 

Trusted  Info.  Sys, 

. (301) 

854-6889 

Technical  Liaison  Committee 

Einar  Stefferud 

NMA-Northrop 

(714) 

842-3711 

Transaction  Processing  SIG 

Andrew  P . Schwartz 

IBM  Corp. 

(415) 

855-4766 

Upper  Layers  SIG 

David  Chappell 

Cray  Research 

(612) 

825-7928 

Virtual  Terminal  SIG 

Cyndi  Jung 

3COM 

(415) 

940-7664 

X.400  SIG 

Barbara  Nelson 

Retix 

(213) 

399-1611 

MAP 

Gary  Workman 

GM 

(313) 

947-0599 

TOP 

Laurie  Bride 

BCS 

(206) 

763-5719 

Government  OSI  Profile 

Jerry  Mulvenna 

NIST 

(301) 

975-3631 
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1.8  PROFILE  CONFORMANCE 


This  section  presents  general  concepts  for  profile  conformance.  These 
concepts  shall  be  observed  when  writing  Implementation  Agreements. 


1,8.1 General  Principle 

Conformance  to  an  OSI  Profile  (Implementation  Agreements, 
Functional  Standards)  implies  conformance  to  the  referenced  Base 
Standards . 

Therefore,  a Profile  shall  not  specify  any  requirement  that  would 
contradict  or  cause  non-conformance  to  the  Base  Standards  to 
which  it  refers  (see  TR  10000-1,  clauses  6.1,  6.3.1).  The 
conformance  requirements  defined  in  ISO/IEC  TR  10000-1  fully 
apply. 


1.8.2 Constraints 


Base  standards  usually  provide  options  for  PDUs , parameters, 
encoding  choices,  value  ranges,  etc. 

A profile  may  make  specific  choices  of  these  options  and  ranges 
of  values.  For  the  promotion  of  interoperability,  pragmatic 
constraints  or  minimum  requirements  may  be  imposed  (e.g.,  the 
limitation  of  Search  operations,  selection  of  encoding  choices, 
value  ranges,  byte  ranges  for  encoding).  These  minimum 
requirements  or  restrictions  shall  not  contradict  the  conformance 
requirements  of  the  respective  base  standards. 


1.8 .2.1  Sending/Encoding  Entity 

In  order  to  promote  interworking,  reasonable  restrictions  or 
minimum  requirements  may  be  specified  in  a profile  as 
described  above. 


1.8. 2. 2  Receiving/Decoding  Entity 

Minirnuun  requirements  of  receiving/decoding  capability  for 
alternatives,  permissible  values,  etc.  may  be  specified  in  a 
profile.  A profile  shall  not  specify  the  behavior  of  a 
receiving/decoding  entity  when  receiving  data  which  is 
outside  the  scope  of  or  excluded  by  the  Profile  for 
senders . 
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A Profile  Conformance  Test  shall  be  limited  by  the  scope  of 
the  profile  specification  and  shall  not  probe  beyond  its 
boundaries.  That  means,  the  capability  of  a 
receiver/decoder  would  be  tested  only  in  the  range  of 
choices  or  values  which  are  specified  for  the 
sending/encoding  entity  (i.e.,  for  interworking  between 
systems  both  being  conformant  to  the  Profile) . 


1.8.3 Classification  of  Conformance 


Conformance  requirements  of  a profile  shall  be  related  to 
conformance  requirements  of  a base  standard  as  written  in  clause 
6.5  and  annex  C of  ISO/IEC  TR  10000-1.  For  the  conformance 
classes,  the  following  terminology  shall  be  used,  unless 
otherwise  specified  by  the  base  standard: 

m mandatory 

0 optional 

c conditional 

X excluded 

1 out  of  scope 
not  applicable 
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2.  SUB  NETWORKS 


Editor's  Note:  All  references  to  Stable  Agreements  in  this  Section  are 
to  Version  3,  Edition  2,  dated  March  1990. 


2.1 INTRODUCTION 

(Refer  to  Stable  Implementation  Agreements  Document) 


2,2  SCOPE  AND  FIELD  OF  APPLICATION 


(Refer  to  Stable  Implementation  Agreements  Document) 


2 ■ 3 STATUS 


This  material  is  current  as  of  March  16,  1990. 

Editor's  Note:  The  FDDI  material  in  particular  has  been 
identified  as  a candidate  for  stability  in  June 
1990. 


2 . 4 ERRATA 

Errata  are  reflected  in  pages  of  Version  3,  Edition  2,  Stable 
Document,  dated  March  1990. 

2.5  LOCAL  AREA  NETWORKS 

(Refer  to  Stable  Implementation  Agreements  Document) 

2.5.1  IEEE  802.2  Logical  Link  Control 

(Refer  to  Stable  Implementation  Agreements  Document) 

2.5.2  IEEE  802.3  CSMA/CD  Access  Method 

(Refer  to  Stable  Implementation  Agreements  Document) 
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2.5.3  IEEE  802.4  Token  Bus  Access  Method 

(Refer  to  Stable  Implementation  Agreements  Document) 


2.5.4  IEEE  802.5  Token  Ring  Access  Method 

(Refer  to  Stable  Implementation  Agreements  Document) 


2.5.5  Fiber  Distributed  Data  Interface  (FDDI) 

2. 5. 5.1  Token  Ring  Media  Access  Control  (MAC.  X3. 139-1987) 

The  following  are  implementation  agreements  with  respect  to 

FDDI  MAC. 

1 The  address  length  shall  be  48  bits. 

2 The  term  "default"  is  defined  to  be  the  value  of  a 
parameter  in  an  FDDI  station  or  concentrator  as 
originally  supplied  by  the  vendor.  Stations  need 
not  be  reset  to  the  default  values  by  a power  off 
condition,  but  there  shall  be  some  manual  or 
programmatic  means  of  resetting  stations  and 
concentrators  to  the  specified  default  values. 

3 The  default  value  of  T_Max  shall  be  at  least  165 
milliseconds  and  not  more  than  200  milliseconds. 

4 The  value  of  T_Req  shall  be  equal  to  T_Max  unless 
set  otherwise  by  the  Network  Manager  or  by  a 
concentrator  initializing  a slave  tree  to  achieve 
"graceful  insertion". 
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All  FDDI  stations  shall  process  Info_Fields  of  0 
to  4478  bytes.  The  frame  is  defined  as  follows: 


p 

SD 

FC 

DA 

SA 

Info 

[— 

FCS 

ED 

FS 

Figure  2.1.  FDDI  FRAME  FORMAT. 


SD 

FC 

DA 

SA 

INFO 

FCS 

ED: 

FS: 


Preamble 

- 16  Idle  Symbols  for  Transmitting 

- >=6  Idle  S)mibols  for  Copying 

- >=2  Idle  Symbols  for  Repeating 
Starting  Delimiter  (2  Symbols,  JK) 
Frame  Control  (2  Symbols) 
Destination  Address  (12  Symbols) 
Source  Address  (12  Symbols) 
Information  Field  (=<8956  Symbols) 
Frame  Check  Sequence  (8  Symbols) 
Ending  Delimiter  (1  Symbol) 

Frame  Status  (3  S3nnbols) 


Stations  shall  not  use  restricted  token  service 


2. 5. 5. 2 Token  Ring  Physical  Level  (PHY. X3 . 148-1988) 

The  following  implementation  agreement  is  with  respect  to 
the  FDDI  PHY  specifications. 

1 The  delay,  that  is  the  time  between  when  a station 
receives  a Starting  Delimiter  (JK  symbol  pair) 
until  it  repeats  that  Starting  Delimiter,  when 
that  Starting  Delimiter  is  preceded  by  a sequence 
of  a Starting  Delimiter  followed  by  50  Idle 
Symbols  shall  not  exceed: 

one  microsecond  in  a station,  and 

one  microsecond  times  the  number  of 
ports  in  a concentrator,  in  addition  to 
the  delays  contributed  by  the  active 
slaves  of  the  concentrator. 


The  measurement  method  described  above  allows  a 
consistent  repeatable  measurement,  however  it  does 
not  measure  maximum  possible  delay.  When  the 
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delay  is  one  microsecond  as  measured  above,  the 
maximum  effective  delay  contribution  component 
which  can  result  is  1.164  microseconds.  This 
number,  not  one  microsecond,  should  be  used  per 
PHY  to  compute  maximum  possible  network  delay. 


2. 5. 5. 3 Physical  Laver  Media  Dependent  (PMD.  X3. 166-1989) 

The  following  implementation  agreements  are  with  respect  to 
the  FDDI  PMD  specification. 

1 Stations  shall  repeat  all  valid  packets  under  all 
signal  conditions  specified  in  Section  5.2, 
"Active  Input  Interface",  with  a bit  error  rate 
(BER)  of  not  more  than  2.5  x 10" 10. 

2 Stations  shall  repeat  all  valid  packets  under  all 
signal  conditions  specified  in  section  5.2, 
"Active  Input  Interface",  except  that  the  Minimum 
Average  Power  shall  be  -29  dBm  (2  dB  above  the 
specified  minimum) , with  a BER  of  not  more  than 
10"12. 


2.6  X.25  WIDE  AREA  NETWORKS 


2.6.1 Introduction 


(Refer  to  the  Stable  Implementation  Agreements  Document) . 


2.6.2  ISO  7776 


(Refer  to  the  Stable  Implementation  Agreements  Document) . 


2.6.3  ISO  8208 


(Refer  to  the  Stable  Implementation  Agreements  Document) . 


2.7  INTEGRATED  SERVICES  DIGITAL  NETWORKS  (ISDN) 
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2.7.1  Introduction 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

2.7.2  Implementation  Agreements 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

2. 7. 2.1  Physical  Laver.  Basic  Access  at  "U” 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

1.1 .1.1  Physical  Laver.  Basic  Access  at  S and  T 
(Refer  to  the  Stable  Implementation  Agreements  Document) . 

2. 7. 2. 3 Physical  Layer.  Primary  Rate  at  "U" 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

2. 7. 2. 4 Data  Link  Laver.  D- Channel 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

1.1. 1.5  Signaling 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

1.1 .1.5  Data  Link  Layer  B-Channel 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

1.1. 1.1  Packet  Laver 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 
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2.8  APPENDIX  A 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 

2.8.1  Data  Link  Laver.  D-Channel 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 

2.8.2  Signaling 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 
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3.  NETWORK  LAYER 


Editor's  Note:  All  references  to  Stable  Agreements  in  this  Section  are 
to  Version  3,  Edition  2,  dated  March  1990. 


3 . 1 INTRODUCTION 


(Refer  to  the  Stable  Agreements  Document) 


3.2  SCOPE  AND  FIELD  OF  APPLICATION 


(Refer  to  the  Stable  Agreements  Document) 


3 ■ 3 STATUS 


This  material  is  current  as  of  March  16,  1990. 

Editor's  Note:  The  priority  material  (Sections  3.5.1  and  3.11) 
and  the  addressing  material  (Section  3.7)  should 
be  examined  closely  for  possible  stability  in  June 
1990. 


3 ■ 4 ERRATA 

Errata  are  reflected  in  pages  of  Version  3,  Edition  2 Stable  Document, 
dated  June  1990. 

3.5  CONNECTIONLESS -MODE  NETWORK  SERVICE  (CLNS) 

3,5.1  ISO  8473 

1.  Subsets  of  the  protocol: 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

2.  Mandatory  Functions: 

(Refer  to  the  Stable  Implementation  Agreements  Document) . 

3.  Optional  Functions: 

o (Refer  to  the  Stable  Implementations  Agreements 
document) . 
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o  Intermediate  systems  implementing  priority  shall  do  so 
as  described  below.  For  End  system  network  entities  the 
implementation  of  priority  is  optional,  but  if 
implemented  it  shall  also  be  done  as  described  below. 

1 NPDUs  shall  be  scheduled  based  on  the  priority 
functions  of  ISP  8473.  The  scheduling  algorithm 
for  achieving  this  priority  function  is  left  as  a 
local  matter.  It  is  required  that  the  following 
constraints  be  met  as  described  below. 

An  NPDU  of  lower  priority  shall  not  overtake 
an  NPDU  of  higher  priority  in  an 
intermediate  system  (i.e.,  exit  an  IS  ahead 
of  a higher  priority  NPDU  arriving  before 
it)  . 

A minimum  flow  shall  be  provided  for  lower 
priority  PDUs.^ 

2 According  to  ISO  8473,  the  priority  level  is  a 
binary  number  with  a range  of  0000  0000  (lowest 
priority)  to  0000  1111  (highest  priority  level). 
Within  this  range,  the  four  abstract  values 
corresponding  to  the  four  levels  defined  in 
section  3.11  shall  be  encoded  as  follows: 

"high  reserved"  priority  will  be  encoded  with 
value  14  (0000  0000  0000  1110), 

"high"  priority  will  be  encoded  with  value  10 
(0000  0000  0000  1010), 

"normal"  priority  will  be  encoded  with  value 
5 (0000  0000  0000  0101),  and 

"low"  priority  will  be  encoded  with  value 
"zero"  (0000  0000  0000  0000) 

For  a receiving  network  entity,  a value  lower  than 
5 shall  be  considered  as  "low";  a value  lower  than 
10  and  higher  than  5 shall  be  considered  as 
"normal",  and  a value  lower  than  14  and  higher 
than  10  shall  be  considered  as  "high". 


1 


The  scheduling  algorithm  by  which  this  is  accomplished  is  for 
further  study. 
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3 Network  entities  supporting  priority  shall  process 
PDUs  in  which  the  priority  parameter  is  absent  as 
either  "low",  "normal",  or  "high"  according  to  a 
locally  configurable  parameter.  This  is  to  ensure 
that  NPDUs  not  containing  the  priority  parameter 
can  be  processed  by  intermediate  systems  in  a 
defined  manner  with  respect  to  those  which  do 
contain  the  priority  parameter. 

4 IEEE  802.4  and  IEEE  802.5  local  area  networks  as 
well  as  some  X.25  networks  implementations  have 
the  ability  to  support  subnetwork  priorities. 

When  available,  a subnetwork  priority  function 
should  be  utilized  in  support  of  the  priority 
requested  of  the  network  layer.  The  mapping  of 
network  layer  priority  levels  onto  subnetwork 
priority  levels  is  a local  configuration  matter. 


3.5.2 Provision  of  CLNS  over  Local  Area  Networks 

(Refer  to  the  Stable  Agreements  Document) 

3.5.3 Provision  of  CLNS  over  X.25  Subnetworks 

(Refer  to  the  Stable  Agreements  Document) 

3.5.4  Provision  of  CLNS  over  ISDN 

(Refer  to  the  Stable  Implementation  Agreements  document) . 


3.5.4. 1 CLNP  Utilizing  X.25  Services 

(Refer  to  the  Stable  Implementations  Agreements  document) . 

3.5.5  Provision  of  CLNS  over  Point- to-Point  Links 

(To  be  based  on  ISO  8880) 

3.6  CONNECTION-MODE  NETWORK  SERVICE 
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3.6.1  Mandatory  Method  of  Providing  CONS 

3. 6. 1.1  General 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3. 6. 1.2  X.25  WAN 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3.6. 1 .3  LANs 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3. 6. 1.4  ISDN 

(Refer  to  the  Stable  Implementation  Agreements  document) . 


3 . 6 . 1 . 5  PRIORITY 


Priority  for  CONS  will  be  addressed  with  the  implementation 
of  X. 25-1988  in  a future  version  of  these  agreements. 


3.6.2 Additional  Option:  Provision  of  CONS  over  X.25  1980 

Subnetworks 

(Refer  to  the  Stable  Implementation  Agreements  Document) 

3.6.3  Agreements  on  Protocols 

(Refer  to  the  Stable  Implementation  Agreements  Document) 

3. 6. 3.1  ISO  8878 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 

3. 6. 3. 2 Subnetwork  Dependent  Convergence  Protocol  (ISO 

8878/Annex  A) 

(Refer  to  the  Stable  Implementation  Agreements  Document) 
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3.6.4 Interworking 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 


3.7  ADDRESSING 

Refer  to  the  Stable  Implementations  Agreements  Document 

o Within  routing  domains  intending  to  operate  using  the  IS  -IS 
Intradomain  Routing  Protocol  defined  in  ISO/IEC  JTC  1/SC  6 
N4945,  it  is  recommended  that  the  DSP  have  a binary  abstract 
syntax  and  that  the  last  nine  octets  are  structured  as 
follows : 


2 octets 


6 octets 


1 octet 


AREA 


ID  N-Selector 


where  the  AREA  field  identifies  a unique  subdomain  of  the 
routing  domain,  the  ID  field  identifies  a unique  system 
within  an  area,  and  an  N-SELECTOR  identifies  a user  of  the 
Network  Layer  Service. 

See  the  OSI  Routing  Framework  document  (ISO/TR  9575)  for 
definitions  of  the  above  terms  and  concepts. 

The  above  recommendation  may  be  applicable  in  other  routing 
environments . 


3 . 8  ROUTING 


3.8.1 End  System  to  Intermediate  System  Routing 

(Refer  to  the  Stable  Implementation  Agreements  Document.) 


3.8.2 Intermediate  Systems  to  Intermediate  Systems  Routine 

(Refer  to  the  Stable  Implementation  Agreements) 


3.9  PROCEDURES  FOR  OSI  NETWORK  SERVICE /PROTOCOL  IDENTIFICATION 


3-5 


March  1990  (Working) 


3.9.1  General 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3.9.2 Processing  of  Protocol  Identifiers 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3. 9. 2.1  Originating  NPDUs 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3. 9. 2. 2 Destination  System  Processing 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3. 9. 2. 3 Further  Processing  in  Originating  End  System 

(Refer  to  the  Stable  Implementation  Agreements  document) . 

3.9.3  Applicable  Protocol  Identifiers 

(Refer  to  the  Stable  Implementation  Agreements  document.) 

3.10  MIGRATION  CONSIDERATIONS 

This  section  considers  problems  arising  from  evolving  OSI  standards 
and  implementations  based  on  earlier  versions  of  OSI  standards. 


3.10.1  X. 25-1980 


(Refer  to  the  Stable  Agreements  Document) 


3.11  USE  OF  PRIORITY^ 


^ This  section  provides  initial  proposals  on  the  use  of  priority. 
The  proposal  requires  further  technical  review  before  considering 
it  as  having  support  as  an  implementation  agreement.  Refer  to 
the  following  documents  for  further  technical  information: 
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3.11.1 Introduction 

Within  the  OSI  environment,  Quality  of  Service  (QoS)  parameters 
are  intended  to  influence  the  qualitative  behavior  of  the  various 
OSI  Layer  entities.  QoS  is  described  in  terms  of  parajneters 
related  to  performance,  accuracy,  and  reliability  (e.g.  delay, 
throughput,  priority,  error  rate,  security,  failure  probability, 
and  etc . ) . 

QoS  covers  a broad  spectrtim  of  issues.  As  a first  step,  these 
agreements  address  the  efficient  sharing  of  Layer  1,  2,  & 3 
transmission  resources  by  making  use  of  the  priority  parameter. 

To  accomplish  this,  implementation  agreements  and  encodings  are 
provided  for  Network  and  Transport  Layer  protocols.  The 
implication  of  these  agreement  for  upper  layer  protocols  is 
limited  to  the  conveyance  of  priority  information  in  both 
directions  between  an  application  entity  and  the  service  boundary 
for  the  Transport  Layer. 

The  implementation  of  priority  as  defined  herein  is  optional  for 
intermediate  systems  and  end  systems,  but  if  implemented  shall  be 
as  defined  in  the  layer  specific  agreements  (for  Network  Layer 
see  section  3.5.1;  for  Transport  Layer  see  section  4. 5. 1.2. 6,  and 
for  Upper  Layers  the  section  will  be  included  at  a later  date) . 


3.11.2 Overview 

The  purpose  of  the  priority  parameter,  in  the  context  of  the 
lower  layers,  is  to  influence  the  scheduling  of  the  transmission 
of  data  on  subnetworks,  in  CONS  as  well  as  CLNS  environments  (end 
systems  as  well  as  intermediate  systems).  The  priority  parameter 
as  defined  is  to  be  used  by  OSI  Applications  to  control  the 
"priority  of  data".  Within  the  lower  layers  this  translates  into 
a contention  for  transmission  resources,  which  has  a direct 
impact  on  performance. 

In  order  to  implement  practical  mechanisms  for  scheduling  the 
transmission  of  data  units  while  maintaining  the  usefulness  of 
priority,  the  specification  of  priority  levels  is  limited  to 
four;  one  corresponding  to  each  of  the  four  service  classes: 

o low  priority 

o normal  priority 


LLSIG  38-64  LLSIG  88-120  LLSIG  88-122 
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o high  priority 

o high  reserved  priority 

The  high  reserved  priority  level  is  intended  primarily  for  OSI 
network  management  purposes.  The  three  lower  priority  levels  are 
intended  for  information  exchange  by  users. 

These  four  priority  levels  are  used,  from  an  applications  point 
of  view,  in  the  various  communications  lower  layers  (Transport, 
Network  and  Data  Link)  to  provide  a consistent  mapping  of 
"abstract  priority  levels"  in  and  n-service  onto  the  n-1  service 
and  v/hen  available,  priority  parameter  values  in  the  layer 
protocol.  In  the  upper  layers  (ASCE,  Presentation  and  Session) 
local  mechanisms  are  expected  to  be  provided  to  application  layer 
ASEs  with  a means  for  conveying  priority  information  in  both 
directions  through  the  communication  upper  layers. 

For  example,  this  implies  that  an  application  request  for  a high 
priority  service  will  be  conveyed  through 

association/presentation/session  and  will  result  in  a high 
priority  data  transport  connection  and  either  high  priority  data 
CLNP  PDUs  (CLNS  case)  or  a high  priority  data  network 
connection/X. 25  virtual  call  (CONS  case). 


3.12  CONFORMANCE 


(Agreements  to  be  added  at  a later  date) 


3.13  APPENDIX  A 

This  appendix  discusses  a problem  concerning  the  operation  of  the  ES- 
IS  routing  protocol  of  ISO  9542  in  an  IEEE  802.5  LAN.  The  proposal 
requires  further  technical  review  before  considering  it  as  having 
support  as  an  implementation  agreement. 

Editor's  Note:  This  Appendix  represents  a discussion  paper 
introduced  by  one  or  a small  number  of  LLSIG 
participants,  and  is  reprinted  here  solely  for 
future  consideration  of  the  SIC.  THIS  IS  NOT  AN 
IMPLEMENTATION  AGREEMENT,  AND  MAY  BE  REMOVED  IN 
THE  FUTURE. 


3.13.1  Problem  Statement 


3-8 


March  1990  (Working) 


o From  NIST  Stable  Implementors’  Agreements  of  March,  1989, 
section  3.8.1  defines  the  following  subnet  point  of 
attachment  multicast  addresses  to  support  ES-IS: 

ALL_ESN  = 0900  2B00  0004 

ALL_ISN  = 0900  2B00  0005 

o Claim  is  that  these  addresses  work  fine  in  IEEE802 . 3 and 
IEEE802.4  subnet  environments,  but  will  not  work  in 
practical  real-world  token  ring  IEEE802.5  networks. 

o A "practical,  real-world"  token  ring  network  is  one  in  which 
the  token  ring  LAN  adapter  is  either  a certain  token  ring 
adapter  or  one  compatible  to  this  kind  of  token  ring 
adapter. 

o Proof  of  this  is  that  a certain  vendor  may  have  a large 
share  of  the  IEEE802.5  token  ring  market.  Most  other 
vendors  providing  token  ring  adapters  probably  need  to  be 
compatible  to  adapters  produced  by  this  vendor. 

o There  are  2 problems: 

NOTATIONAL  - i.e.,  describing  the  ES-IS  multicast 

addresses  in  the  agreements  for  token 
ring  in  an  unambiguous  fashion 
SUBSTANTIVE  - Certain  adapters  do  not  allow  the  full 
range  of  possible  IEEE802.5  multicast 
addresses.  Concepts  of  "group"  and 
"functional"  multicast  addresses  are 
defined  and  these  are  the  only  types 
allowed.  Anything  else  will  be  rejected 
by  such  adapters.  The  current  agreed 
upon  ES-IS  multicast  addresses  do  not 
fit  the  form  accepted  by  these  adapters. 


3.13,2 Address  Notational  Considerations 

o When  an  octet  of  an  address  string  is  written  down  in  HEX 
notation,  it  represents  8 bits  with  the  following 
convention: 

The  least  significant  bit  (LSB)  of  the  octet  is  on  the 
right  side  and  the  most  significant  bit  is  on  the  left 
side.  This  is  the  opposite  to  the  conventions  used  in 
the  IEEE802  MAC  level  standards. 
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o So  for  the  first  octet  of  the  ES-IS  multicasts  given  in 
implementors  agreements: 

0X09  = 0 0 0 0 1 0 01 

MSB  LSB 


U/L  I/G 
2ND  1ST 
XMT  XMT 
BIT  BIT 

I/G  = Individual/Group  (I.E.  Multicast)  BIT 
U/L  = Universal/Locally  Assigned  BIT 

In  all  IEEE802  MAC  Standards,  I/G  always  transmitted 
first  and  U/L  always  transmitted  next. 

o In  IEEE802.3  and  IEEE802.4  in  each  octet  the  LSB  is 
transmitted  first 

o In  IEEE802.5  in  each  octet  the  MSBof  the  information  field 
is  transmitted  first.  The  address  field  Bits  are 
transmitted  in  the  sequence  of  48  bits  starting  with  I/G. 
Notationally  to  describe  the  address  fields  like  the 
information  fields,  keeping  the  convention  of  MSB  Bit 
transmitted  first,  the  first  octet  of  the  address  field  is 
written  as  follows: 

0X90  =10010000 
MSB  LSB 

I/G  U/L 
1ST  2ND 
XMT  XMT 
BIT  BIT 

o Note  in  IEEE802.5,  the  bits  of  the  first  octet  go  out  with 
I/G  first  and  U/L  second  as  for  IEEE802.3  and  IEEE802.4. 
However,  the  conventional  computer  science  notation  to 
represent  the  octets  is  reversed  since  in  this  notation  LSB 
is  always  written  to  the  right. 

o Therefore,  minimally  we  need  to  reverse  the  notation  used  in 
the  implementor'  agreements  to  represent  the  ES-IS  multicast 
addresses  for  IEEE802.5. 
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3.13.3 Requirement  to  Use  Functional  Addressing 

o Certain  adapters  do  not  support  arbitrary  multicast  IEEE802 
addresses  (with  first  xmitted  bit  I/G  set  to  1). 

o 2 classes  of  valid  multicasts: 

Group  addresses  (what  standard  calls  conventional  group 
mode)  - only  1 such  address  can  be  registered  with  the 
adapter  and  therefore  cannot  be  used  for  ES-IS 

Functional  address  (what  standard  calls  bit-significant 
mode)  - Some  are  reserved;  however,  12  of  these  user 
defined.  Has  format: 

11000000  00000000  Followed  by 
OXXXXXXX  XXXXXXXX  XXXXXXXX  XXXXXXXX 

IX  Set  to  1 with  remaining  X's  set  to  0. 

o Anything  else  rejected  by  adapter  or  will  not  be  properly 
filtered. 

o Using  conventional  computer  science  notation: 

First  2 functional  address  octets  = OXCO  0X00 


3.13.4 Proposal  to  Revise  Agreements 

o In  section  3.8.1,  delete  Item  #9  and  replace  with  a new  #9 
and  #10  as  follows: 

9.  The  multicast  addresses  corresponding  to  "all 

intermediate  systems  on  the  network"  (ALL_ISN)  and  "All 
End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to 
the  following  on  IEEE802.3  and  IEEE802.4  subnetworks: 

ALL_ESN  = 0900  2B00  0004 
ALL_ISN  = 0900  2B00  0005 

It  is  understood  that  the  hexadecimal  octets  shown  are 
transmitted  onto  the  medium  form  left  most  octet  to 
right  most  octet.  Within  each  hexadecimal  octet  the 
least  significant  bit  is  transmitted  first. 

10.  The  multicast  addresses  corresponding  to  "All 

Intermediate  Systems  on  the  network"  (ALL-ISN)  and  "All 
End  systems  on  the  Network"  (ALL_ESN)  shall  default  to 
the  following  two  functional  addresses  on  IEEE802.5 
subnetworks : 
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ALL_ESN  = COOO  0000  4000 
ALL  ISN  = COOO  0000  8000 


It  is  understood  that  the  hexadecimal  octets  shown  are 
transmitted  onto  the  medium  from  left  most  octet  to 
right  most  octet.  Within  each  hexadecimal  octet  the 
most  significant  bit  is  transmitted  first." 

o Renumber  the  current  Items  10  and  11  of  this  Section  to 
11  and  12,  respectively. 

o Editor's  Note:  It  is  recommended  that  the  particular 

final  choice  of  functional  addresses 
selected  by  the  SIG  be  verified  with 
the  vendor  who  has  volunteered  these 
functional  addresses  for  this  purpose. 
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4.  TRANSPORT  LAYER 

Editor's  Note:  All  references  to  Stable  Agreements  in  this  Section  are 
to  Version  3,  Edition  2,  dated  March  1990. 


4 . 1 INTRODUCTION 

(Refer  to  Stable  Implementation  Agreements  Docuiaent) 


4.2  SCOPE _AND  FIELD  OF  APPLICATION 

(Refer  to  the  Stable  Implementation  Agreements  document) . 


4 ■ 3 STATUS 

This  material  is  current  as  of  March  16,  1990. 

Editor's  Note:  The  priority  material  (sec.  4. 5. 1.2. 6)  in 
particular  has  been  identified  as  a candidate  for 
stability  in  June  1990. 


4 . 4 ERRATA 

Errata  are  reflected  in  pages  of  Version  3,  Edition  2,  Stable 
Document,  dated  March  1990. 

4.4.1 ISO/CCITT  Defect  Reports 

This  section  lists  the  defect  reports  from  ISO  which  are 
currently  recognized  to  be  valid  for  the  purpose  of  NIST 
conformance . 


4,5  PROVISION  OF  CONNECTION  MODE  TRANSPORT  SERVICES 

(Refer  to  the  Stable  Implementation  Agreements  document) . 


4.5.1  Tr^sport  Class  ,4 


4. 5. 1.1  Transport  Class  4 Overview 

(Refer  to  the  Stable  Implementation  Agreements  document) . 
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4. 5. 1,2  Protocol  Agreements 

4.5.1, 2.1  General  Rules 

(Refer  to  the  Stable  Implementation  Agreements 
Document . ) 


4. 5. 1.2. 2  Transport  Class  4 Service  Access  Points  or 
Selectors 


(Refer  to  the  Stable  Implementation  Agreements 
Document . ) 


4 . 5. 1.2. 3  Retransmission  Timer 


(Refer  to  the  Stable  Implementation  Agreements 
Document . ) 


4. 5. 1.2. 4  Keep-Alive  Function 

(Refer  to  the  Stable  Implementation  Agreements 
Document . ) 


4.5. 1.2.5  Congestion  Avoidance  Policies 

(Refer  to  the  Stable  Implementation  Agreements 
Document) . 


4. 5. 1.2. 6  Use  of  Priority— 

For  end  systems,  the  implementation  of  priority  is  optional, 
but  if  implemented,  one  of  the  four  values  defined  in 
section  3.11  shall  always  be  used  in  an  instance  of 
communications.  In  other  words  an  explicit  priority 
parameter  shall  be  sent. 

Additional  requirements  of  systems  implementing  priority  are 
defined  below. 

1 When  Transport  is  implemented  over  a CLNS  Network 

entity,  each  data  TPDU  and  corresponding  NSDU  shall  be 
assigned  a priority  level  derived  from  the  Transport 
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connection  priority  level,  except  as  excluded  in  item 
5b  and  5d  below^. 

2 A local  mechanism  shall  be  provided  to  convey  priority 
information  to  the  Network  service.  If  appropriate, 
simultaneous  Transport  service  request  can  be  managed 
on  a priority  basis  within  the  Transport  Layer. 

3 The  four  abstract  values  corresponding  to  the  four 
levels  defined  in  3.11  shall  be  encoded  as  follows:^ 

"high  reserved"  priority  will  be  encoded  with 
value  "zero"  (0000  0000  0000  0000) , and 

"high"  priority  will  be  encoded  with  value  5 

(0000  0000  0000  0101), 

"normal"  priority  will  be  encoded  with  value  10 
(0000  0000  0000  1010), 

"low"  priority  will  be  encoded  with  value  14 

(0000  0000  0000  1110) 

4 Other  values  should  be  interpreted  as  follows:  a value 
lower  than  5 and  higher  than  0 shall  be  interpreted  as 
"high",  a value  lower  than  10  and  higher  that  5 shall 
be  interpreted  as  "normal",  and  a value  higher  than  10 
shall  be  interpreted  as  "low". 

5 The  exchange  of  priority  parameters  by  Transport 
entities  is  performed  as  described  below^. 

a If  priority  is  implemented  in  the  end  system,  a 
priority  value  corresponding  to  one  of  the  four 
abstract  levels  defined  in  section  3.11  will  be 
conveyed  down  to  the  Transport  entity  and  shall  be 
encoded  and  sent  in  the  CR  TPDU  as  the  priority 
level  "desired"  for  the  Transport  connection. 

b A receiving  Transport  entity  supporting  priority 
management  shall  either  accept  the  priority  level 
proposed  in  the  CR  TPDU  or  select  a lower  level. 


^ The  approach  to  assigning  priority  to  an  NSDU  is  for  further  study. 

^ This  encoding  has  been  chosen  to  be  consistent  with  ISO  8073, 

The  results  is  a reverse  encoding  from  that  for  ISO  8473. 

^ ISO  8073  does  not  define  or  support  a sound  negotiation  mechanism 
at  this  time;  the  following  process  will  serve  to  allow  a 
priority  level  to  be  established  for  a TC. 
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The  CR  shall  not  be  rejected  solely  because  of  the 
"desired"  priority  level.  The  selected  priority 
level  shall  be  encoded  and  returned  to  the  calling 
Transport  entity  in  the  CC  TPDU.  The  TC  priority 
is  also  passed  to  the  local  session  entity  with 
the  T-Connect  indication  primitive  and  is 
eventually  conveyed  to  the  ASE,  which  can  reject 
the  association  if  the  priority  is  unacceptable. 

If  the  receiving  Transport  entity  supports 
priority  but  receives  a CR  TPDU  without  the 
priority  parameter,  it  shall  associate  a default 
priority  level  with  the  Transport  connection  for 
the  purposes  of  managing  the  Transport  connections 
which  may  be  under  its  control.  This  default 
level  shall  not  be  encoded  and  placed  in  the 
corresponding  CC  TPDU  and  shall  not  result  in  any 
priority  information  being  associated  with  NSDUs 
being  passed  to  the  Network  entity  supporting  the 
Transport  connection.  The  default  shall  be  either 
"low",  "normal",  or  "high"  according  to  the 
locally  configurable  parameter. 

c A receiving  Transport  entity  not  supporting 

priority  management  shall  ignore  the  parameter  in 
the  CR  TPDU. 

d When  the  initiating  Transport  entity  receives  the 
CC  TPDU  containing  the  priority  parameter,  it 
establishes  the  priority  for  the  Transport 
connection  based  on  the  level  received  and  conveys 
this  to  the  session  entity  with  the  T-Connect 
confirm  primitive.  If  the  priority  parameter  does 
not  appear  in  the  CC  TPDU,  the  initiating 
Transport  entity  shall  assume  the  remote  Transport 
entity  does  not  support  priority  and  will 
therefore  assign  a default  priority  level  to  the 
Transport  connection  for  the  purposes  of  managing 
the  Transport  connection  with  respect  to  the  other 
simultaneous  Transport  connections  which  may  be 
under  its  control.  However,  this  default  shall 
not  result  in  any  priority  information  being 
associated  with  NSDUs  being  passed  to  the  Network 
entity  supporting  the  Transport  connection.  The 
default  shall  be  either  "low",  "normal",  or  "high" 
according  to  a locally  configurable  parameter. 


4.5.2 Transport  Class  0 
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(Refer  to  Stable  Implementation  Agreements  Document) 

4. 5. 2.1  Transport  Class  0 Overview 

(Refer  to  Stable  Implementation  Agreements  Document) 

4. 5. 2. 2 Protocol  Agreements 

4. 5. 2. 2.1  Transport  Class  0 Service  Access  Points 

(Refer  to  Stable  Implementation  Agreements  Document) 

4. 5. 2. 3 Rules  for  Negotiation 

(Refer  to  Stable  Implementation  Agreements  Document.) 

4.5.3 Transport  Class  2 

(Refer  to  Stable  Implementation  Agreements  Document.) 

4. 5. 3.1  Transport  Class  2 Overview 

(Refer  to  Stable  Implementation  Agreements  Document.) 

4. 5. 3. 2 Protocol  Agreements 

(Refer  to  Stable  Implementation  Agreements  Document.) 

4.6  PROVISION  OF  CONNECTIONLESS  TRANSPORT  SERVICE 

(Refer  to  Stable  Implementation  Agreements  Document.) 

4.7  TRANSPORT  PROTOCOL  IDENTIFICATION 

(Refer  to  the  Stable  Implementation  Agreements  document.) 
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5.  UPPER  LAYERS 


Editor's  Note:  All  references  to  Stable  Agreements  in  this  section  are 
to  Version  3,  Edition  2,  March  1990. 


5.1  INTRODUCTION 


(Refer  to  Stable  Agreements  Document) 


5.1.1  References 


(Refer  to  Stable  Agreements  Document) 


5.2  SCOPE  AND  FIELD  OF  APPLICATION 


(Refer  to  Stable  Agreements  Document) 


5.3  STATUS 


This  version  of  the  upper  layer  agreements  is  under  development. 


5.4  ERRATA 


5.4.1  ISO  Defect  Solutions 


(Refer  to  Stable  Agreements  Document) 


5.4.2  Session  Defect  Solutions  Correcting  CCITT  X.215  and 
X.225 


(Refer  to  Stable  Agreements  Document) 


5.5  ASSOCIATION  CONTROL  SERVICE  ELEMENT 


5.5.1  Introduction 


(Refer  to  Stable  Agreements  Document) 
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5.5.2  Services 

(Refer  to  Stable  Agreements  Document) 

5.5.3  Protocol  Agreements 

5 . 5 . 3 . 1 Application  Context 
(Refer  to  Stable  Agreements  Document) 


5. 5. 3. 2 AE  Title 

(Refer  to  Stable  Agreements  Document) 


5 . 5 . 3 . 3  Result  Parameter 


If  the  result  parameter  of  the  AARE  PDU  contains  the 
accepted,  then  the  result-source-diagnostic  parameter 
contain  the  value  null. 


5.5.4  ASN.l  Encoding  Rules 
(Refer  to  Stable  Agreements  Document) 


5.5.5  Connectionless 


(Refer  to  Stable  Agreements  Document) 


5.6  ROSE 


(Refer  to  Stable  Agreements  Document) 


5.7  RISE 


(Refer  to  Stable  Agreements  Document) 


5.8  PRESENTATION 


value 

shall 
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5.8.1  Introduction 

(Refer  to  Stable  Agreements  Document) 

5.8.2  Service 

(Refer  to  Stable  Agreements  Document) 

5.8.3  Protocol  Agreements 


5 . 8 . 3 . 1 Transfer  Syntaxes 

(Refer  to  Stable  Agreements  Document) 

5 . 8 . 3 . 2 Presentation  Context  Identifier 
(Refer  to  Stable  Agreements  Document) 


5 . 8 . 3 . 3  Default  Context 

(Refer  to  Stable  Agreements  Document) 


5. 8. 3. 4  P-Selectors 


(Refer  to  Stable  Agreements  Docioment) 


5 . 8 . 3 . 5  Provider  Abort  Parameters 
(Refer  to  Stable  Agreements  Document) 


5 . 8 . 3 . 6  Provider  Aborts  and  Session  Version 
(Refer  to  Stable  Agreements  Document) 


5. 8. 3. 7  CPC-Tvpe 

(Refer  to  Stable  Agreements  Document) 


5-3 


March  1990  (Working) 


5 . 8 ■ 3 ■ 8 Presentation-context -definition- result- list 

(Refer  to  Stable  Agreements  Document) 

5. 8.3. 9 RS-PPDU 

(Refer  to  Stable  Agreements  Document) 

5.8.4  Presentation  ASN.l  Encoding  Rules 

5 . 8 . 4 . 1 Invalid  Encoding 

(Refer  to  Stable  Agreements  Document) 

5.8.5  General 

5 . 8 . 5 . 1 Presentation  Data  Value  (PDV) 

(Refer  to  Stable  Agreements  Document) 


5.8.6 

Connection  Oriented 

(Refer  to  Stable  Agreements 

Document) 

5.8.7 

Connectionless 

(Refer  to  Stable  Agreements 

Document) 

SESSION 

5.9.1 

Introduction 

(Refer  to  Stable  Agreements 

Document) 

5.9.2 

Services 

(Refer  to  Stable  Agreements 

Document) 
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5.9.3  Protocol  Agreements 


5 . 9 . 3 . 1 Concatenation 

(Refer  to  Stable  Agreements  Document) 

5 . 9 . 3 . 2 Segmenting 

(Refer  to  Stable  Agreements  Document) 

5 . 9 . 3 . 3 Reuse  of  Transport  Connection 
(Refer  to  Stable  Agreements  Document) 


5 . 9 . 3 . 4 Use  of  Transport  Expedited  Data 
(Refer  to  Stable  Agreements  Document) 

5 . 9 . 3 . 5 Use  of  Session  Version  Number 
(Refer  to  Stable  Agreements  Document) 

5 . 9 . 3 . 6 Receipt  of  Invalid  SPDUs 
(Refer  to  Stable  Agreements  Document) 


5 . 9 . 3 . 7  Invalid  SPM  Intersections 
(Refer  to  Stable  Agreements  Document) 


5 . 9 . 3 . 8  S-Selectors 

(Refer  to  Stable  Agreements  Document) 


5.9.4  Connectionless 

(Refer  to  Stable  Agreements  Document) 
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5,10 


UNIVERSAL  ASN.l  ENCODING  RULES 

5.10.1  TAGS 

(Refer  to  Stable  Agreements  Document) 

5.10.2  Definite  Length 

(Refer  to  Stable  Agreements  Document) 

5.10.3  EXTERNAL 

(Refer  to  Stable  Agreements  Document) 


5.10.4  Integer 

(Refer  to  Stable  Agreements  Document) 


5.10.5  String  Types 

(Refer  to  Stable  Agreements  Document) 


5.10.6  Bit  String 

(Refer  to  Stable  Agreements  Document) 
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5.11  CHARACTER  SETS 


(Refer  to  chapter  21  --a  new  chapter  expressly  for  character 

sets . ) 
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5.12  CONFORMANCE 

(Refer  to  Stable  Agreements  Document) 

5.12.1  Specific  ASE  Requirements 
(Refer  to  Stable  Agreements  Document) 

5.12.1.1  FTAM 

5. 12.1. 1.1  Phase  2 

(Refer  to  Stable  Agreements  Document) 

5.12.1.2  MRS 

5.12.1.2.1  Phase  1 (1984  X.400) 

(Refer  to  Stable  Agreements  Document) 

5.12.1.2.2  Phase  2,  Protocol  Pi  (1988  X.400) 
(Refer  to  Stable  Agreements  Document) 

5.12.1.2.3  Phase  2.  Protocol  P7  (1988  X.400) 

(Refer  to  Stable  Agreements  Document) 

5.12.1.2.4  Phase  2,  Protocol  P3  (1988  X.400) 

(Refer  to  Stable  Agreements  Document) 

5.12.1.3  M 

5.12.1.3.1  Phase  1 

(Refer  to  Stable  Agreements  Document) 
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5.12,1.4  Virtual  Terminal 


5.12.1.4.1  Phase  la 

(Refer  to  Stable  Agreements  Document) 

5.12.1.4.2  Phase  lb 

(Refer  to  Stable  Agreements  Document) 

5.12.1.5  MMS 
For  further  study. 


5.12.1.6  Transaction  Processing 

ACSE  Requirements : 

all 

Application  Context: 

The  application  context  is  user-defined. 

Presentation  Requirements: 

Presentation  Functional  Units: 
o kernel 

Presentation  Contexts: 

o At  least  3 must  be  supported  if  the  commit 

functional  unit  of  TP  is  not  supported, 
o At  least  4 must  be  supported  if  the  commit 

functional  unit  of  TP  is.  supported. 

Abstract  Syntaxes: 
o "ISO  8650-ACSEl" 

{ j oint- iso-ccitt (2)  association-control(2) 
abstract-syntax(l)  apdus(O)  versionl(l)  ) 

Associated  Transfer  Syntax: 

o "Basic  Encoding  of  a single  ASN.l  type" 

{ joint-iso-ccitt(2)  asnl(l) 

basic-encoding(l)  ) 

o "ISO  10026-TP" 

{ joint-iso-ccitt(2)  transaction- 
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processing(?)  abstract-syntax(2)  tp-apdus(l) 

) 

Associated  Transfer  Syntax: 

o "Basic  Encoding  of  a single  ASN.l  type" 

{ joint- iso-ccitt (2)  asnl(l) 

basic-encoding( 1 ) } 

o If  required,  "ISO  9804-CCR" 

(TBD) 

o At  least  one  user-defined  abstract  syntax. 

Session  Requirements: 

Session  Functional  Units: 
o kernel 

o duplex 

o Others  as  required  by  CCR  (TBD)  if  the 

commit  functional  unit  of  TP  is 

supported. 

Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 


5.13  APPENDIX  A:  RECOMMENDED  PRACTICES 


(Refer  to  Stable  Agreements  Document) 
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5.14  APPENDIX  B:  OBJECT  IDENTIFIER  REGISTER 


5.14.1 

Register  Index 

(Refer  to  Stable  Agreements  Document) 

5.14.2  Object  Identifier  Descriptions 
(Refer  to  Stable  Agreements  Document) 
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6.  REGISTRATION  AUTHORITY  PROCEDURES  FOR  THE  OSI  IMPLEMENTORS  WORKSHOP 

(OIW) 

For  current  Registration  Authority  information  for  Workshop- -Defined 
Objects,  consult  the  aligned  chapter  of  Version  3,  Edition  2,  Stable 
Implementation  Agreements  dated  March  1990. 


6-1 


March  1990  (Working) 


7.  STABLE  MESSAGE  HANDLING  SYSTEMS 


Editor's  Note:  For  current  stable  MRS  agreements,  consult  the  aligned 
section  in  the  Stable  Implementation  Agreements 
document.  This  section  serves  as  a reference  or 
pointer  to  Stable  Agreements  contained  in  Version  3, 
Edition  2,  March  1990. 
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8.  MESSAGE  HANDLING  SYSTEMS 

8 ■ 1 INTRODUCTION 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8.2  SCOPE 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8 . 3 STATUS 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  December 
1989. 

8 . 4 ERRATA 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  December 
1989. 

8.5  MT  KERNEL 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8.5.1  Introduction 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.5.2  Elements  of  Service 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.5.3  MTS  Transfer  Protocol  (PI) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.5.4  MTS  - APDU  Size 
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This  section  is  for  further  study  by  the  NIST  X.400  SIG.  The  following 
support  requirement  may  be  increased  in  the  future. 

The  following  agreements  govern  the  size  of  MPDUs: 

o All  MTAEs  must  support  at  least  one  MPDU  of  at  least  two  megabyte, 
o The  size  of  the  largest  MPDU  supported  by  a UAE  is  a local  matter. 


8.5.5 1988/84  Interworking  Considerations 

Editor's  Note:  References  to  Section  7 are  to  the  Stable 
Dociunent . 

An  MTA  conforming  to  this  Agreement  will  downgrade  1988  PI  to  1984  PI 
when  relaying  to  1984-based  MTAs , as  specified  in  Annex  B of  X.419  with 
the  following  additional  requirements: 

o Supplementary  Information  - will  need  to  be  truncated  if  it 

exceeds  the  pragmatic  constraint  identified  in  Version  2 of  these 
Agreements  (64  octets  as  opposed  to  256  octets  in  the  1988  MRS 
standards) , and 

o Internal  Trace  Information  - If  the  1984-based  MTA  does  not 
support  Internal  Trace  Information  per  Section  7. 7. 3. 2,  the 
following  description  is  not  applicable.  When  a 1988-based  MTA 
supports  intei'working  with  a i984-based  MTA  that  generates 
Internal  Trace  Information  as  per  Section  7. 7. 3. 3,  the  1988-based 
MTA  must  support  reception  of  the  Internal  Trace  Information  by 
converting  the  Internal  Trace  Information  from  the  form  in  Section 
7. 7. 3. 2 to  the  form  specified  in  1988  X.411,  as  per  the  following 
description.  When  the  1988-based  MTA  sends  to  a 1984  MTA,  the 
1988-based  MTA  must  apply  the  conversion  to  1984,  as  described 
below.  The  Stable  NBS  Implementors  Agreements  X.400  (1984) 
implementors'  agreements  definition  for  MTA's  Internal  Trace 
Information  is  different  from  the  X.400  (1988)  MTA  definition. 
Consequently,  a X.400  (1988)  MTA  operating  in  an  MD  with  other 
MTAs  of  1984  vintage,  must  map  the  Internal  Trace  Information  to 
and/or  from  the  1984  format. 

What  follows  are  algorithms  for  mapping  between  X.400  (1988) 
Internal  Trace  element  formats  and  the  NIST  lA  X.400  (1984) 
Internal  Trace  element  format. 

To  avoid  potential  looping  within  a MD  composed  of  1984  and  1988 
vintage  MTAs,  MD  administrators  are  strongly  advised  to  name  all 
MTAs  (1984  and  1988  vintages)  using  only  the  Printable  String 
characters.  In  X.400  (1988)  the  MTA-Name  is  defined  to  be  named 
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using  IA5  String  characters  where  in  the  lAs  for  X.400  (1984) 

MTAs , NBS  restricted  the  MTA-Name  to  be  formed  using  the  Printable 
String  character  subset  of  IA5.  If  the  1988-based  MTA  Name  uses 
IA5  characters  not  in  the  Printable  String  subset,  that  Internal 
Trace  Element  should  be  omitted  when  converting  from  1988  to  1984. 

1988  to  1984  Mapping 


For  each  Internal  Trace  element  in  the  sequence: 

DO 

IF  MTA-Name  is  made  up  of  non-Printable  String  characters: 

Discard  this  Internal  Trace  element; 

ELSE 

{ Discard  the  GlobalDomainIdentifier ; 

Copy  the  MTAname  over; 

Within  the  MTASuppliedInformation: 

Copy  the  arrival  time  over; 

Copy  the  routing  action  over; 

IF  attempted  is  present 
{ IF  it  is  a domain: 

Discard  it; 

IF  it  is  an  MTA: 

Copy  it  to  Previous  MTAName; 

) 

IF  the  additional  actions  are  present: 

{ IF  the  deferred  time  is  present: 

Copy  it  over; 

IF  the  other-actions  is  present: 

Discard  it; 

} 

} 

END -DO 
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1984  to  1988  Mapping 


Find  the  [APPLICATION  30)  entry  in  the  PI  envelope; 

FOR  each  Internal  Trace  element: 

DO 

Insert  the  GlobalDomainIdentif ier  of  this  MTA; 

Copy  the  MTAName  over; 

Within  the  MTASuppliedInfo : 

Copy  the  arrival  time; 

IF  the  deferred  time  is  present: 

copy  it  to  the  additional  actions  field  within  the 
1988  Internal  Trace  information; 

IF  the  routing  action  is  Relayed  or  Rerouted: 
copy  it  over; 

IF  the  routing  action  is  Recipient-reassigned: 
map  to  Relayed; 

IF  the  previous  MTAName  is  present: 

copy  it  to  the  MTAName  in  the  attempted  field; 

END -DO 


8,6  I PM  KERNEL 


8.6.1  Introduction 


See  Stable  Implementation  Agreements  Version  3,  Edition  2 dated  March 
1990. 


8.7  MESSAGE  STORE 


8.7.1  Introduction 


See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.2  Scope 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 
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8.7.3  Elements  of  Service 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.4  Attribute  Types 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.5  Pragmatic  Constraints  for  Attribute  Types 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.6 Implementation  of  the  MS  with  1984  Systems 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.7  MS  Access  Protocol  (P7) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.7.8  MTS  Access  Protocol  (P3) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.8  REMOTE  USER  AGENT  SUPPORT 

8.8.1 Introduction 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 


8-5 


March  1990  (Working) 


8.8.2  Scone 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.8.3  Elements  of  Service 


See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 


8.8.4 MTS  Access  Protocol  (P3) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 


8.9  NAMING.  ADDRESSING  & ROUTING 

8.9.1  Use  of  0/R  Addresses  for  Routine 

It  is  recognized  that  these  Agreements  enable  a wide  variety  of  naming 
and  addressing  attributes.  Each  domain  may  adopt  particular  routing 
schemes  within  its  domain. 

These  agreements  make  no  attempt  to  recommend  a standard  practice  for 
electronic  mail  addressing. 

Addressing  may  be  secured  according  to  practices  outside  the  scope  of 
these  agreements,  such  as: 

o manual  directories 
o on-line  directories,  such  as  X.500 
o ORName  address  translation  algorithms. 

8.9.2  Distribution  Lists 


8.9.2. 1 Introduction 


This  section  identifies  and  specifies  the  Distribution  Lists 
Functional  Group,  which  covers  all  issues  relating  to  the 
performance  of  distribution  list  (DL)  expansion  by  an  MTA.  Other 
aspects  concerned  with  the  use  of  distribution  lists  are  covered 
in  the  MT  Kernel  and  IPM  Kernel  Functional  Groups. 
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8, 9. 2. 2 Elements  of  Service 


This  section  specifies  the  requirements  for  support  of  Elements  of 
Service  for  conformance  to  the  Distribution  Lists  Functional  Group 
of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as 
defined  in  Section  8.5.2. 

Support  for  Elements  of  Service  is  specified  for  the  MT  Service 
only,  and  is  only  concerned  with  the  performance  of  DL  expansion 
by  an  MTA.  Such  support  is  in  addition  to  the  support 
requirements  specified  in  Section  8.5  if  this  Functional  Group  is 
supported.  Support  for  IPM  Elements  of  Service  for  use  of 
distribution  lists  is  as  specified  in  Section  8.6. 

Table  8.13  Distribution  Lists:  MT  Elements  of  Service 


Element  of  Service 

Support 

DL  Expansion  History  Indication 

M 

DL  Expansion  Prohibited 

M 

Use  of  Distribution  List 

M 

8.9.3 MHS  Use  of  Directory 


8 ,9. 3.1  Introduction 


The  MHS  standards  recognize  the  need  of  MHS  users  for  a number  of 
directory  service  elements.  Directory  service  elements  are 
intended  to  assist  users  and  their  UAs  in  obtaining  information 
for  use  in  submitting  messages  for  delivery  by  the  MTS. 

The  MTS  may  also  use  the  directory  service  elements  to  obtain 
information,  for  example,  to  be  used  in  the  routing  of  messages. 
This  application  of  the  directory  service  is  not  defined  by  the 
base  standards  and  is  therefore  not  addressed  by  this  Agreement. 


8. 9. 3. 2 Functional  Gonf iguration 

Two  MHS  functional  entities,  the  IPM  UA  and  MTA,  may  access  the 
Directory  service  using  the  Directory  User  Agent  (DUA) . The 
interface  between  the  UA  and  DUA,  or  MTA  and  DUA  is  local  and  not 
defined.  The  interaction  between  the  DUA  and  Directory  System 
Agent  (DSA)  is  specified  in  Ghapter  11.  A collocated  DUA  and  DSA 
is  also  permitted. 
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8. 9. 3. 3 Func tlonalitv 

Some  functional  usages  of  directories  have  been  identified  for  UAs 
and  the  MTAs . These  are: 

UA  Specific  Functionality: 

o Verify  the  existence  of  a Directory  Name, 
o Given  a partial  name,  return  a list  of  possibilities, 
o Ability  to  scan  directory  entries. 

o Return  the  0/R  Address (es)  that  correspond  to  a Directory 
Name . 

o Determine  whether  a Directory  Name  presented  denotes  a user  or 
a Distribution  List. 

o Return  the  members  of  a Distribution  List. 

o Return  the  capabilities  of  the  entity  referred  to  by  a 
Directory  Name. 

o Maintenance  functions  to  keep  the  directory  up-to-date,  e.g. 
register  and  change  credentials. 

MTA  Specific  Functionality: 

o Authentication. 

o Return  the  0/R  Address (es)  that  correspond  to  a Directory 
Name . 

o Determine  whether  a Directory  Name  presented  denotes  a user  or 
a Distribution  List. 

o Return  the  members  of  a Distribution  List. 

o Return  the  capabilities  of  the  entity  referred  to  by  a 
Directory  Name. 

o Maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a number  of  operational  aspects  must 
be  considered.  These  include  user-friendliness,  flexibility, 
availability,  expandability  and  reliability. 
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8. 9. 3. 4 Naming  and  Attributes 

Since  user-friendliness  is  of  primary  importance  in  a messaging 
system,  the  naming  conventions  used  in  building  the  Directory 
Information  Tree  (DIT)  will  impact  the  ability  of  a user  to  make 
intelligent  guesses  for  Directory  Names. 

It  is  recommended  that  the  naming  guidelines  and  DIT  structures 
defined  in  Annex  B of  Recommendation  X.52i/ISO  9594-7  be  used  as 
the  basis  for  MHS  Directory  Names.  Annex  C of  Recommendation 
X. 402/ISO  10021-2  specifies  further  the  MHS  specific  object 
classes.  The  naming  for  MHS  specific  object  classes  are 
recommended  as  follows: 

(i)  the  naming  for  mhs-message-store , mhs-message-transfer-agent , 
and  mhs-user-agent  is  that  of  Application  Entity  in  the  DIT. 

(ii)  the  naming  attribute  for  mhs-distribution-list  is 
commonName.  The  organization,  organizationalUnit , 
organizationalRole , organizationaiPerson,  Locality,  or 
groupOfNamss  can  be  immediate  superior  to  entries  of 
object  class  m.hs-distribution-list. 

(iii)  the  naming  for  mhs-user  is  that  of  organizationaiPerson, 
ResidentialPerson,  organizationalRole,  organizationalUnit, 
organization,  or  Locality. 

Note:  The  mhs-user  object  class  is  a generic  object  class 

which  may  be  used  in  conjunction  with  another  standard 
object  class  for  the  purpose  of  adding  MHS  information 
attributes,  such  as  ORAddresses,  to  a Directory  entry. 
The  means  to  associate  attributes  of  a generic  object 
class  to  an  entry  (or  to  different  entries)  named  by  a 
standard  object  class(es)  is  by  defining  a new 
(un- )registered  object  class,  whose  superclass (es)  is 
that  of  the  naming  object  class(es),  and  of  the 
generic  object  class.  E.g.,  to  associate  mhs-user 
attributes  in  the  organizationaiPerson  entry,  the  new 
unregistered  object  class  can  be  defined  as  shown  in 
Figure  8.9. 


reai-user-entry  : :=  OBJECT  CLASS 

SUBCLASS  OF  organizationaiPerson, 
mhs-user 


Figure  8.9  Example  of  Unregistered  Object  Class  Definition 
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The  MHS  object  classes,  attributes,  and  attribute  S3nritaxes  that 
need  to  be  supported  by  the  Directory  are  as  specified  in  Annex  C 
of  Recommendation  X. 402/ISO  10021-2. 

In  addition,  the  object  classes  organization,  organizationalUnit , 
organizationalRole , organizationaiPerson,  locality,  groupOfNames , 
residentialPerson,  and  country  and  their  attributes  and  associated 
syntaxes  as  defined  in  X,520  (ISO  9594,  Part  6)  and  X.521  (ISO 
9594,  Part  7)  are  required  to  support  the  MHS. 


8. 9. 3. 5 Elements  of  Service 


This  section  specifies  the  requirements  for  support  of  Elements  of 
Service  for  conformance  to  the  Use  of  Directory  Functional  Group 
of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as 
defined  in  Section  8.5.2. 


Support  for  Elements  of  Service  is  specified  both  for  the  MT 
Service  and  for  the  IPM  Service . 

Table  8.14  Use  of  Directory:  MT  Elements  of  Service 


Element  of  Service 

Origination 

— 

Reception 

~"j 

Relay  | 

Designation  of  Recipient  by 
Directory  Name 

M 

M 

- 

Table  8.15  Use  of  Directory:  IPM  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Designation  of  Recipient  by 
Directory  Name 

M 

- 

8.10  MHS  MANAGEMENT 


For  further  study. 
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8.11  MHS  SECURITY 


8.11.1  Introduction 


This  section  identifies  and  specifies  the  MHS  Security  Functional 
Group,  which  is  intended  to  cover  all  issues  relating  to  provision  of 
secure  messaging  and  secure  access  management  facilities  by  an  MHS 
implementation. 


3.11.2  Elements  of  Service 


This  section  specifies  the  requirements  for  support  of  Elements  of 
Service  for  conformance  to  the  MHS  Security  Functional  Group  of  this 
Agreement . 

The  classification  scheme  for  support  of  Elements  of  Service  is  as 
defined  in  Section  8.5.2. 

Support  for  Elements  of  Service  is  specified  both  for  the  MT  Service 
and  for  the  IPM  Service  (Note:  All  Elements  of  Service  listed  below  are 
1988) 


Table  8.16  MHS  Security:  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Content  Confidentiality 

* 

* 

Content  Integrity 

* 

* 

Message  Flow  Confidentiality 

* 

* 

Message  Origin  Authentication 

* 

* 

Message  Security  Labelling 

■* 

* 

Message  Sequence  Integrity 

* 

■k 

Non-repudiation  of  Delivery 

* 

k 

Non-repudiation  of  Origin 

* 

k 

Non-repudiation  of  Submission 

* 

k 

Probe  Origin  Authentication 

* 

k 

Proof  of  Delivery 

* 

k 

Proof  of  Submission 

* 

k 

Report  Origin  Authentication 

* 

k 

Secure  Access  Management 

* 

k 
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Table  8.17  MRS  Security:  IPM  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Content  Confidentiality 

* 

* 

Content  Integrity 

* 

* 

Message  Flow  Confidentiality 

* 

■k 

Message  Origin  Authentication 

* 

* 

Message  Security  Labelling 

* 

k 

Message  Sequence  Integrity 

* 

k 

Non-repudiation  of  Delivery 

* 

k 

Non-repudiation  of  Origin 

* 

k 

Non-repudiation  of  Submission 

* 

k 

Probe  Origin  Authentication 

* 

k 

Proof  of  Delivery 

* 

k 

Proof  of  Submission 

* 

k 

Report  Origin  Authentication 

* 

k 

Secure  Access  Management 

* 

k 

8.12  SPECIALIZED  ACCESS 


8.12.1  Physical  Delivery 

8.12.1.1  Introduction 

This  section  identifies  and  specifies  the  Physical  Delivery 
Functional  Group,  which  is  intended  to  cover  all  issues  relating 
to  access  to  physical  delivery  systems  by  an  MHS  implementation. 


8.12.1.2 Elements  of  Service 


This  section  specifies  the  requirements  for  support  of  Elements  of 
Service  for  conformance  to  the  Physical  Delivery  Functional  Group 
of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as 
defined  in  Section  8.5.2. 

Support  for  Elements  of  Service  is  specified  both  for  the  MT 
Service  and  for  the  IPM  Service  (Note:  All  Elements  of  Service 
listed  below  are  1988) . 
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Table  8.18  Physical  Delivery:  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Additional  Physical  Rendition 

0 

0 

Basic  Physical  Rendition 

M 

M 

Counter  Collection 

M 

M 

Counter  Collection  with  Advice 

0 

0 

Delivery  via  Bureaufax  Service 

0 

0 

ElMS  (Express  Mail  Service) 

M 

M 

Ordinary  Mail 

Physical  Delivery  Notification 

M 

M 

by  MHS 

Physical  Delivery  Notification 

0 

0 

by  PDS 

0 

0 

Physical  Forwarding  Allowed 

M 

M 

Physical  Forwarding  Prohibited 

M 

M 

Registered  Mail 

Registered  Mail  to  Addressee 

0 

0 

in  Person 

0 

0 

Request  for  Forwarding  Address 

0 

0 

Special  Delivery 

Undeliverable  Mail  with  Return 

M 

M 

of  Physical  Message 

M 

M 
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Table  8.19  Physical  Delivery:  IPM  Elements  of  Service 


Element  of  Service 

Origination 
(IPM  UA) 

Reception 

(PDAU) 

Additional  Physical  Rendition 

0 

0^ 

0 

Basic  Physical  Rendition 

M 

Counter  Collection 

M 

M 

Counter  Collection  with  Advice 

0 

0 

Delivery  via  Bureaufax  Service 

0 

0 

EMS  (Express  Mail  Service) 

M 

m2 

Ordinary  Mail 

0^ 

M 

Physical  Delivery  Notification 
by  MHS 

0 

0 

Physical  Delivery  Notification 
by  PDS 

0 

M 

Physical  Forwarding  Allowed 

0^ 

M 

Physical  Forwarding  Prohibited 

M 

M 

Registered  Mail 

0 

0 

Registered  Mail  to  Addressee 
in  Person 

0 

0 

Request  for  Forwarding  Address 

0 

0 

Special  Delivery 

M 

m2 

Undeliverable  Mail  with  Return 
of  Physical  Message 

0^ 

M 

Notes : 

1)  Provided  by  default  (when  using  a physical  delivery 

address) . 

2)  Must  support  EMS  and/or  Special  Delivery. 

8-14 


March  1990  (Working) 


Table  8.20  Physical  Delivery  0/R  Address  Attributes 


0/R  Address  Attribute  Type 

UA 

Orig 

PDAU 

Recep 

administration-domain-name 

M 

M 

country-name 

M 

M 

private -domain-name 

M 

M 

physical -delivery- service -name 

0 

M 

phys ical - de 1 ivery- country-name 

M 

M 

postal-code 

M 

M 

extension-postal -0/R- address -components 

0 

M 

extens ion-phys ical - de 1 ivery - address  - components 

0 

M 

local -postal -at tributes 

0 

M 

phys ical -del ivery- office -name 

0 

M 

phys ical -del ivery- office -number 

0 

M 

phy s ical - del ivery- organization-name 

0 

M 

phys i c a 1 - de 1 i ve  ry -personal- name 

0 

M 

post-office -box- address 

0 

M 

pos te - res tante- address 

0 

M 

street -address 

0 

M 

unformat ted- postal -address 

M 

M 

unique -postal -name 

0 

M 

The  handling  of  Printable  Strings  and  Teletex  Strings  in  0/R 
address  components  is  for  further  study. 


Table  8.21  Character  String  Support 


Origination 

Reception 

Character  String 

(IPM  UA) 

(PDAU) 

Printable 

* 

M 

Teletex 

* 

M 

8.12.2  Other  Access  Units 


8.12.2.1 Facsimile  Access  Units 


The  possible  development  of  Agreements  in  this  area  is  for  further 
s tudy . 
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8.12.2.2  Telex  Access  Units 

It  is  not  currently  intended  to  develop  Agreements  in  this  area. 

8.12.2.3  Teletex  Access  Units 


It  is  not  currently  intended  to  develop  Agreements  in  this  area. 


8.13  CONVERSION 


8.13.1  Introduction 


This  section  identifies  and  specifies  the  Conversion  Functional  Group, 
which  is  intended  to  cover  all  issues  relating  to  support  of  conversion 
facilities  by  an  MTA. 


8.13.2  Elements  of  Seirvice 


This  section  specifies  the  requirements  for  support  of  Elements  of 
Service  for  conformance  to  the  Conversion  Functional  Group  of  this 
Agreement , 

The  classification  scheme  for  support  of  Elements  of  Service  is  as 
defined  in  Section  8.5,2. 

Support  for  Elements  of  Service  is  specified  for  the  MT  Service  only, 
and  is  only  concerned  with  the  performance  of  conversion  by  an  MTA. 

Such  support  is  in  addition  to  the  support  requirements  specified  in 
Section  8.5  if  this  Functional  Group  is  supported.  Support  for  IPM 
Elements  of  Service  for  access  to  conversion  facilities  is  as  specified 
in  Section  8.6. 


8-16 


March  1990  (Working) 


Table  8.22  Conversion:  MT  Elements  of  Service 


Element  of  Service 

Support 

Conversion  Prohibition  in  Case 

of  Loss  of  Information  (1988) 

* 

Explicit  Conversion 

* 

Implicit  Conversion 

ic 

8.14  USE  OF  UNDERLYING  LAYERS 

8.14.1  MTS  Transfer  Protocol  (Pi) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.14.2  MTS  Access  Protocol  (P3)  and  MS  Access  Protocol  (P7) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.15  ERROR  HANDLING 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8.15.1  PDU  Encoding 

8.15.2  Contents 

8.15.3  Envelope 

8.15.4  Reports 

8.15.5  Pragmatic  Constraints 

If  an  implementation  detects  a pragmatic  constraint  violation,  then  it 
may  generate  an  appropriate  error  indication  but  is  not  required  to  do 
so . 
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8.16  CONFORMANCE 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8.17  APPENDIX  A:  MHS  PROTOCOL  SPECIFICATIONS 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March  1990. 

8.17.1  MTS  Transfer  Protocol  (PI) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.17.2  Interpersonal  Messaging  Protocol  (P2) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.17.3  MTS  Access  Protocol  (P3) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.17.4  MS  Access  Protocol  (P7) 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.17.5  Message  Store  General  Attribute  Support 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.17.6  Message  Store  IPM  Attribute  Support 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 


8-18 


March  1990  (Working) 


8.18  APPENDIX  B:  INTERPRETATION  OF  ELEMENTS  OF  SERVICE 


The  objective  of  this  section  is  to  provide  clarification,  where  required, 
on  the  functionality  of  Elements  of  Service  where  the  MRS  standards  are 
unclear  or  ambiguous.  It  is  not  the  intent  of  this  section  to  define  how 
information  should  be  made  available  or  presented  to  an  MHS  user,  nor  is  it 
intended  to  define  how  individual  vendors  should  design  their  products. 

The  following  MHS  Elements  of  Service  require  further  text  to  be  added  to 
their  definitions  to  represent  the  proposed  implementation  of  these  Elements 
of  Service  for  conformance  to  this  Agreement.  Elements  of  Service  which  are 
not  referenced  in  this  section  are  as  defined  in  the  MHS  base  standards. 

Reply  Request  Indication 

The  reply-recipients  and  the  reply-time  may  be  specified  without  any 
explicit  reply  being  requested.  This  may  be  interpreted  by  the  recipient  as 
an  implicit  reply  request.  Note  that  for  an  auto -forwarded  message  an 
explicit  or  implicit  reply  request  may  not  be  meaningful. 

Forwarded  IP-message  Indication 

The  following  use  of  the  original  encoded  information  type  in  the  context  of 
forwarded  messages  is  clarified: 

o The  encoded  information  types  of  the  message  being  forwarded  should  be 
reflected  in  the  new  original  encoded  Information  t3rpes  being 
generated. 

o If  forx^arding  a private  message  body  part,  the  originator  of  the 

forwarded  message  shall  set  the  original  encoded  information  types  in 
the  PI  envelope  to  Undefined  for  that  body  part. 
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8.19  APPENDIX  C:  RECOMMENDED  PRACTICES 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.19.1  Printable  String 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.19.2  Rendition  of  lASText 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated  March 
1990. 

8.19.3  EDI  Use  of  MHS 

8.19.3.1 Introduction  and  Scope 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated 
March  1990. 


8.19.3.2  Model 


See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated 
March  1990. 


8.19.3.3  Protocol  Elements  Supported  for  EDI 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated 
March  1990. 


8.19,3.4  Addressing  and  Routing 

See  Stable  Implementation  Agreements,  Version  3,  Edition  2 dated 
March  1990. 
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8.20  APPENDIX  D:  LIST  OF  ASN. 


8.20.1  Content  Types 

8.20.2  Body  Part  Types 


OBJECT  IDENTIFIERS 


8-21 


March  1990  (Working) 


9.  STABLE  FTAM  PHASE  2 


Editor's  Note:  For  Stable  FTAM  Phase  2 Agreements,  consult  the  aligned 

section  in  the  Stable  Implementation  Agreements  Document. 
This  section  serves  as  a reference  or  pointer  to  Stable 
Agreements  contained  in  Version  3,  Edition  2,  March  1990. 
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10.  ISO  FILE  TRANSFER.  ACCESS  AND  MANAGEMENT  PHASE  3 

Editor's  Note:  For  current  Stable  FTAM  Phase  3 Agreements, 

consult  the  aligned  section  in  the  Stable 
Implementation  Agreements,  Version  3,  Edition  2, 
dated  March  1990. 
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11  DIRECTORY  SERVICES  PROTOCOLS 

11.1  INTRODUCTION 

Refer  to  section  11.1  of  Stable  Agreements  Version  3 Edition  2. 

11.2  SCOPE  AND  FIELD  OF  APPLICATION 

Refer  to  section  11.2  of  Stable  Agreements  Version  3 Edition  2. 

11.3  STATUS 

Refer  to  section  11.3  of  Stable  Agreements  Version  3 Edition  2. 

11.4  USE  OF  THE  DIRECTORY 

This  section  will  contain  introductory  text. 

11.4.1  MHS 
(TBD) 

11.4.2  FTAM 
(TBD) 

11.5  DIRECTORY  ASEs  AND  APPLICATION  CONTEXTS 

Refer  to  section  11.5  of  Stable  Agreements  Version  3 Edition  2. 

11.6  SCHEMA 

Refer  to  section  11.6  of  Stable  Agreements  Version  3 Edition  2. 

11.6.1  Support  of  Structures  and  Naming  Rules 

Refer  to  section  11.6.1  of  Stable  Agreements  Version  3 Edition  2. 

11.6.2  Support  of  Object  Classes  and  Subclasses 

Refer  to  section  11.6.2  of  Stable  Agreements  Version  3 Edition  2. 


11  - 1 


March  1990  (Working) 


11.6.3  Support  of  Attribute  Types 

Refer  to  section  11.6.3  of  Stable  Agreements  Version  3 Edition  2. 

11.6.4  Support  of  Attribute  Syntaxes 

Refer  to  section  11.6.4  of  Stable  Agreements  Version  3 Edition  2. 

11.6.5  Naming  Contexts 

Refer  to  section  11.6.5  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6  Common  Profiles 

Refer  to  section  11.6.6  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.1  OIW  Directory  Common  Application  Directory  Profile 
Refer  to  section  11.6.6.1  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.1.1  Standard  Application  Specific  Attributes  and  Attribute  Sets 
Refer  to  section  11.6.6.1.1  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.1.2  Standard  Application  Specific  Object  Classes 
Refer  to  section  11.6.6.1.2  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.2  OIW  Directory  Strong  Authentication  Directory  Profile 
Refer  to  section  11.6.6.2  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.2.1  Other  Profiles  Supported 

Refer  to  section  11.6.6.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.6.6.2.2  Standard  Application  Specific  Object  Classes 
Refer  to  section  11.6.6.2.2  of  Stable  Agreements  Version  3 Edition  2. 
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11.6.7  Restrictions  on  Object  Class  Definitions 

Refer  to  section  11.6.7  of  Stable  Agreements  Version  3 Edition  2. 

11.7  PRAGMATIC  CONSTRAINTS 

Refer  to  section  11.7  of  Stable  Agreements  Version  3 Edition  2. 

11.7.1  General  Constraints 

Refer  to  section  11.7.1  of  Stable  Agreements  Version  3 Edition  2. 

11.7.1.1  Character  Sets 

Refer  to  section  11.7.1.1  of  Stable  Agreements  Version  3 Edition  2. 

11.7.1.2  APDU  Size  Considerations 

Refer  to  section  11.7.1.2  of  Stable  Agreements  Version  3 Edition  2. 

11.7.1.3  Service  Control  (SC)  Considerations 

Refer  to  section  11.7.1.3  of  Stable  Agreements  Version  3 Edition  2. 

11.7.1.4  Priority  Service  Control 

Refer  to  section  11.7.1.4  of  Stable  Agreements  Version  3 Edition  2. 
11.7.2  Constraints  on  Operations 

Refer  to  section  11.7.2  of  Stable  Agreements  Version  3 Edition  2. 

11.7.2.1  Filters 

Refer  to  section  11.7.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.7.2.2  Errors 

Refer  to  section  11.7.2.2  of  Stable  Agreements  Version  3 Edition  2. 
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11.7.2.3  Error  Reporting  — Detection  of  Search  Loop 
Refer  to  section  11.7.2.3  of  Stable  Agreements  Version  3 Edition  2. 

11.7.3  Constraints  Relevant  to  Specific  Attribute  Types 
Refer  to  section  11.7.3  of  Stable  Agreements  Version  3 Edition  2. 

11.8  CONFORMANCE 

Refer  to  section  11.8  of  Stable  Agreements  Version  3 Edition  2. 

11.8.1  DUA  Conformance 

Refer  to  section  11.8.1  of  Stable  Agreements  Version  3 Edition  2. 

11.8.2  DSA  Conformance 

Refer  to  section  11.8.2  of  Stable  Agreements  Version  3 Edition  2. 

11.8.3  DSA  Conformance  Classes 

Refer  to  section  11.8.3  of  Stable  Agreements  Version  3 Edition  2. 

11.8.4  Authentication  Conformance 

Refer  to  section  11.8.4  of  Stable  Agreements  Version  3 Edition  2. 

11.8.5  Directory  Service  Conformance 

Refer  to  section  11.8.5  of  Stable  Agreements  Version  3 Edition  2. 

11.8.6  The  Directory  Access  Profile 

Refer  to  section  11.8.6  of  Stable  Agreements  Version  3 Edition  2. 

11.8.7  The  Directory  System  Profile 

Refer  to  section  11.8.7  of  Stable  Agreements  Version  3 Edition  2. 
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11.8.8  Digital  Signature  Protocol  Conformance  Profile 
Refer  to  section  11.8.8  of  Stable  Agreements  Version  3 Edition  2. 

11.8.9  Strong  Authentication  Protocol  Conformance  Profile 
Refer  to  section  11.8.9  of  Stable  Agreements  Version  3 Edition  2. 

11.9  DISTRIBUTED  OPERATIONS 

Refer  to  section  11.9  of  Stable  Agreements  Version  3 Edition  2. 

11.9.1  Referrals  and  Chaining 

Refer  to  section  11.9.1  of  Stable  Agreements  Version  3 Edition  2. 

11.9.2  Tlrace  Information 

Refer  to  section  11.9.2  of  Stable  Agreements  Version  3 Edition  2. 

11.10  UNDERLYING  SERVICES 

Refer  to  section  11.10  of  Stable  Agreements  Version  3 Edition  2. 

11.10.1  ROSE 

Refer  to  section  11.10.1  of  Stable  Agreements  Version  3 Edition  2. 

11.10.2  Session 

Refer  to  section  11.10.2  of  Stable  Agreements  Version  3 Edition  2. 

11.10.3  ACSE 

Refer  to  section  11.10.3  of  Stable  Agreements  Version  3 Edition  2. 

11.11  ACCESS  CONTROL 

Refer  to  section  11.11  of  Stable  Agreements  Version  3 Edition  2. 
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11.12  TEST  CONSIDERATIONS 

Refer  to  section  11.12  of  Stable  Agreements  Version  3 Edition  2. 

11.12.1  Major  Elements  of  Architecture 

Refer  to  section  11.12.1  of  Stable  Agreements  Version  3 Edition  2. 

11.12.2  Search  Operations 

Refer  to  section  11.12.2  of  Stable  Agreements  Version  3 Edition  2. 

11.13  ERRORS 

Refer  to  section  11.13  of  Stable  Agreements  Version  3 Edition  2. 

11.13.1  Permanent  vs.  Temporary  Service  Errors 

Refer  to  section  11.13.1  of  Stable  Agreements  Version  3 Edition  2. 

11.13.2  Guidelines  for  Error  Handling 

Refer  to  section  11.13.2  of  Stable  Agreements  Version  3 Edition  2. 

11.13.2.1  Introduction 

Refer  to  section  11.13.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.13.2.2  Symptoms 

Refer  to  section  11.13.2.2  of  Stable  Agreements  Version  3 Edition  2. 

11.13.2.3  Situations 

Refer  to  section  11.13.2.3  of  Stable  Agreements  Version  3 Edition  2. 

11.13.2.4  Error  Actions 

Refer  to  section  11.13.2.4  of  Stable  Agreements  Version  3 Edition  2. 


11-6 


March  1990  (Working) 


11.13.2.5  Reporting 

Refer  to  section  11.13.2.5  of  Stable  Agreements  Version  3 Edition  2. 

11.14  SPECIFIC  AUTHENTICATION  SCHEMES 

Refer  to  section  11.14  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1  Specific  Strong  Authentication  Schemes 

Refer  to  section  11.14.1  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1  ElGamal 

Refer  to  section  11.14.1.1  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.1  References 

Refer  to  section  11.14.1.1.1  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.2  Background 

Refer  to  section  11.14.1.1.2  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.3  Digital  Signature 

Refer  to  section  11.14.1.1.3  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.4  Verification 

Refer  to  section  11.14.1.1.4  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.5  Known  Constraints  on  Parameters 

Refer  to  section  11.14.1.1.5  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.1.6  Note  on  subjectPublicKey 

Refer  to  section  11.14.1.1.6  of  Stable  Agreements  Version  3 Edition  2. 
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11.14.1.2  One-Way  Hash  Functions 

Refer  to  section  11.14.1.2  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.2.1  SQUARE— MOD-N  Algorithm 

Refer  to  section  11.14.1.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.2.2  MD2  Algorithm 

Refer  to  section  11.14.1.2.2  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.2.3  Study  of  Other  One-Way  Hash  Functions 
Refer  to  section  11.14.1.2.3  of  Stable  Agreements  Version  3 Edition  2. 


11.14.1.2.4  Use  of  One-Way  Hash  Functions  in  Forming  Signatures 
Refer  to  section  11.14.1.2.4  of  Stable  Agreements  Version  3 Edition  2. 

11.14.1.3  ASN.l  for  Ctrong  Authentication  Algorithms 
Refer  to  section  11.14.1.3  of  Stable  Agreements  Version  3 Edition  2. 

11.14.2  Protected  Simple  Authentication 

Refer  to  section  11.14.2  of  Stable  Agreements  Version  3 Edition  2. 


11.14.3  Simple  Authentication 

There  are  two  major  classes  of  authentication  supported  by  the  Directory  (i.e.,  simple  and 
strong  authentication).  Simple  authentication  is  based  on  a password  being  passed  between 
the  two  associated  entities  (DUA-DSA  or  DSA-DSA).  In  the  case  of  the  DUA-DSA  interac- 
tion, the  password  is  compared  in  some  way  with  the  password  attribute  in  the  user’s  entry 
in  the  Directory.  In  the  case  of  DSA-DSA  interaction,  this  cannot  be  done  since  the  DSA 
object  class,  as  defined  in  the  Directory  Documents  (Part  7,  clause  6.14)  does  not  contain 
a password  attribute. 

To  facilitate  simple  authentication  between  DSAs,  a DSA  shall  have  local  access  to  a list 
of  one  or  more  known  DSAs,  with  a copy  of  each  known  DSA’s  password.  Maintenance  of 
that  information  is  done  through  the  use  of  bilateral  agreements  between  DSA  administrtors. 
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11.15  APPENDIX  A:  MAINTENANCE  OF  ATTRIBUTE  SYN- 
TAXES 

Refer  to  section  11.15  of  Stable  Agreements  Version  3 Edition  2. 

11.15.1  Introduction 

Refer  to  section  11,15.1  of  Stable  Agreements  V^ersion  3 Edition  2. 

11.15.2  General  Rules 

Refer  to  section  11.15.2  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3  Checking  Algorithms 

Refer  to  section  11.15.3  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.1  distinguishedNameSyntax 

Refer  to  section  11.15.3.1  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.2  integerSyntax 

Refer  to  section  11.15.3.2  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.3  teiephoneNumber  Syntax 

Refer  to  section  11.15.3.3  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.4  countryName 

Refer  to  section  11.15.3.4  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.5  preferredDeliveryMethod 

Refer  to  section  11.15.3.5  of  Stable  Agreements  Version  3 Edition  2. 

11.15.3.6  presentationAddress 

Refer  to  section  i 1.1 5, 3, 6 of  Stable  Agreements  Version  3 Edition  2. 
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11.15.4  Matching  Algorithms 

Refer  to  section  11.15.4  of  Stable  Agreements  Version  3 Edition  2. 

11.15.4.1  UTCTimeSyntax 

Refer  to  section  11.15.4.1  of  Stable  Agreements  Version  3 Edition  2. 

11.15.4.2  distinguishedNameSyntax 

Refer  to  section  11.15.4.2  of  Stable  Agreements  Version  3 Edition  2. 

11.15.4.3  caseIgnoreListSyntax 

Refer  to  section  11.15.4.3  of  Stable  Agreements  Version  3 Edition  2. 
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11.16  APPENDIX  B:  GLOSSARY 

Refer  to  section  11.16  of  Stable  Agreements  Version  3 Edition  2. 
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11.17  APPENDIX  C:  REQUIREMENTS  FOR  DISTRIBUTED 
OPERATIONS 

Refer  to  section  11.17  of  Stable  Agreements  Version  3 Edition  2. 

11.17.1  General  Requirements 

Refer  to  section  11.17.1  of  Stable  Agreements  Version  3 Edition  2. 

11.17.2  Protocol  Support 

Refer  to  section  11.17.2  of  Stable  Agreements  Version  3 Edition  2. 

11.17.2.1  Usage  of  ChainingArguments 

Refer  to  section  11.17.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.17.2.2  Usage  of  Chainging  Results 

Refer  to  section  11.17.2.2  of  Stable  Agreements  Version  3 Edition  2. 
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11.18  APPENDIX  D:  GUIDELINE  FOR  APPLICATIONS  US- 
ING THE  DIRECTORY 

Refer  to  section  11.18  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1  Tutorial 

Refer  to  section  11.18.1  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.1  Overview 

Refer  to  section  11.18.1.1  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.2  Use  of  the  Directory  Schema 

Refer  to  section  11.18.1.2  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.2.1  Use  of  Existing  Object  Classes 

Refer  to  section  11.18.1.2.1  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.2.2  Kinds  of  Object  Classes 

Refer  to  section  11.18.1.2.2  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.2.3  Use  of  Unregistered  Object  Classes 

Refer  to  section  11.18.1.2.3  of  Stable  Agreements  Version  3 Edition  2. 

11.18.1.2.4  Side  Effects  of  Creating  Unregistered  Object  Classes 
Refer  to  section  11.18.1.2.4  of  Stable  Agreements  Version  3 Edition  2. 

11.18.2  Creation  of  New  Object  Classes 

Refer  to  section  11.18.2  of  Stable  Agreements  Version  3 Edition  2. 

11.18.2.1  Creation  of  New  Subclasses 

Refer  to  section  11.18.2.1  of  Stable  Agreements  Version  3 Edition  2. 
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11.18.2.2  Creation  of  New  Attributes 

Refer  to  section  11.18.2.2  of  Stable  Agreements  Version  3 Edition  2. 
11.18.3  DIT  Structure  Rules 

Refer  to  section  11.18.3  of  Stable  Agreements  Version  3 Edition  2. 
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11.19  APPENDIX  E:  TEMPLATE  FOR  AN  APPLICATION  SPE- 
CIFIC PROFILE  FOR  USE  OF  THE  DIRECTORY 

Refer  to  section  11.19  of  Stable  Agreements  Version  3 Edition  2. 
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12.  STABLE  SECURITY  AGREEMENTS 

Editor's  Note:  This  section  points  to  Stable  Security 

Agreements  which  are  contained  in  the  aligned 
section  of  the  Stable  Implementation  Agreements, 
Version  3,  Edition  2,  March  1990. 
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13,  SECURITY 

13.1  FORWARD  AND  INTRODUCTION 

13.2  SCOPE  AND  FIELD  OF  APPLICATION 

13.3  REFERENCES 

13.4  DEFINITIONS 

13.4.1  Definitions  of  Elements  of  Services 


Message  Origin  Authentication  MT 

This  element  of  service  allows  the  originator  of  a message  to  provide  to 
the  recipient (s)  of  the  message,  and  any  MTA  through  which  the  message  is 
transferred,  a means  by  which  the  origin  of  the  message  can  be  authen- 
ticated (i.e.  a signature).  Message  Origin  Authentication  can  be 
provided  to  the  recipient (s)  of  the  message,  and  any  MTA  through  which 
the  message  is  transferred,  on  a per-message  basis  using  an  asymmetric 
encryption  technique,  or  can  be  provided  only  to  the  recipient(s)  of  the 
message,  on  a per-recipient  basis  either  a asymmetric  or  a symmetric 
encryption  technique. 

Report  Origin  Authentication  MT 

This  element  of  service  allows  the  originator  of  a message  (or  probe)  to 
authenticate  the  origin  of  a report  on  the  delivery  or  non-delivery  of 
the  subject  message  (or  probe),  (a  signature).  report  Origin  Authen- 
tication is  on  a per-report  basis,  and  uses  an  asymmetric  encryption 
technique , 

Probe  Origin  Authentication  MT 

This  element  of  service  allows  the  originator  of  a probe  to  provide  to 
any  MTA  through  which  the  probe  is  transferred  a means  to  authenticate 
the  origin  of  the  probe  (i.e.  a signature).  Probe  Origin  Authentication 
is  on  a per-probe  basis,  and  uses  an  asymmetric  encryption  technique. 

Proof  of  Delivery  MT 

This  element  of  service  allows  the  originator  of  a message  to  obtain  from 
the  recipient(s)  of  the  message  the  means  to  authenticate  the  identity  of 
the  recipient (s)  and  the  delivered  message  and  content.  Message  reci- 
pient authentication  is  provided  to  the  originator  of  a message  on  a per- 
recipient  basis  using  either  symmetric  or  asymmetric  encryption 

techniques . 

Proof  of  Submission  MT 
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This  element  of  service  allows  the  originator  of  a message  to  obtain  from 
the  MTS  the  means  to  authenticate  that  the  message  was  submitted  for 
delivery  to  the  originally  intended  recipient.  Message  submission 
authentication  is  provided  on  a per-recipient  basis,  and  can  use 
symmetric  or  asymmetric  encryption  techniques. 

Peer  Entity  Authentication  MT 

This  element  of  service  provides  confirmation  of  the  identity  of  the 
Entity  (UA,  MTA,  MS)  . It  provides  confidence  at  the  time  of  usage  only 
that  an  entity  is  not  attempting  to  masquerade  as  an  unauthorized  entity. 

Content  Confidentiality  MT 

This  element  of  service  allows  the  originator  of  a message  to  protect  the 
content  of  the  message  from  disclosure  to  someone  other  than  the  intended 
recipient(s) . Content  Confidentiality  is  on  a per  message  basis,  and  can 
use  either  an  asymmetric  or  a symmetric  encryption  technique. 

Content  Integrity  MT 

This  element  of  service  allows  the  originator  of  the  message  to  provide 

to  the  recipient  of  the  message  a means  by  which  the  recipient  can  verify 
that  the  content  of  the  message  has  not  been  modified.  Content  Integrity 
is  on  a per-recipient  basis,  and  can  use  either  an  asymmetric  or  a 
symmetric  encryption  technique. 

Message  Flow  Confidentiality  MT 

This  element  of  service  allows  the  originator  of  the  message  to  protect 
information  which  might  be  derived  from  observation  of  the  message  flow. 

Message  Sequence  Integrity  MT 

This  element  of  service  allows  the  originator  of  the  message  to  provide 
to  a recipient  of  the  message  a means  by  which  the  recipient  can  verify 
that  the  sequence  of  messages  from  the  originator  to  the  recipient  has 
been  preserved  (without  message  loss,  re-ordering,  or  replay).  Message 
Sequence  Integrity  is  on  a per-recipient  basis,  and  can  use  either  an 
asymmetric  or  a symmetric  encryption  technique. 

Non  Repudiation  of  Origin  MT 

This  element  of  service  allows  the  originator  of  a message  to  provide  the 
recipient(s)  of  the  message  irrevocable  proof  of  the  origin  of  the 
message.  This  will  protect  against  any  attempt  by  the  originator  to 
subsequently  revoke  the  message  or  its  content.  Non  Repudiation  of 
Origin  is  provided  to  the  recipient(s)  of  a message  on  a per  message 
basis  using  asymmetric  encryption  techniques. 
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Non  Repudiation  of  Submission  MT 

This  element  of  service  allows  the  originator  of  a message  to  obtain 
irrevocable  proof  that  a message  was  submitted  to  the  MTS  for  delivery  to 
the  originally  specified  recipient(s) . This  will  protect  against  any 
attempt  by  the  MTS  to  subsequently  deny  that  the  message  was  submitted 
for  delivery  to  the  originally  specified  recipient(s) . Non  Repudiation 
of  Submission  is  provided  to  the  originator  of  a message  on  a per  message 
basis,  and  uses  an  asymmetric  encryption  technique. 

Non  Repudiation  of  Delivery  MT 

This  element  of  service  allows  the  originator  of  a message  to  obtain  from 
the  recipient(s)  of  the  message,  irrevocable  proof  that  the  message  was 
delivered  to  the  recipient(s) . This  will  protect  against  any  attempt  by 
the  recipient(s)  to  subsequently  deny  receiving  the  message  or  its 
content.  Non  Repudiation  of  Delivery  is  provided  to  the  originator  of  a 
message  on  a per-recipient  basis  using  asymmetric  encryption  techniques. 

Access  Control  MT 

This  element  of  service  provides  protection  against  unauthorized  use  of 
the  resources  accessed  via  MHS . Access  decisions  are  directed  by  a 
security  policy  which  may  be  identity  and/or  role  based. 

13.5  ABBREVIATIONS 

13.6  STATUS 

13.7  ERRATA 

13.8  ARCHITECTURES 

13.8.1  Introduction 


Open  Systems  Security  provides  for  secure  distributed  information 
processing  in  an  environment  which  is  heterogeneous  in  terms  of 
technology  and  in  terms  of  administration. 

This  document  will  define  security  for  a target  OIW  development  to: 

a.  provide  security  guidance  to  other  OIW  SICs,  and 

b.  define  a framework  for  an  OIW  security  profile  based  upon 
international  standards  of  draft  international  standards. 

The  objectives  are: 

1.  to  define  a target  secure  OIW  environment; 
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2.  to  support  and  complement  the  other  OIW  SIG  efforts  and  to  integrate 
existing  OIW  security  facilities; 

3.  to  consider  user  requirements  which  may  extend  beyond  the  other  OIW 
protocols  (e.g.  secure  routing  mechanisms,  security  administration); 

4.  to  support  basic  OSI  communication  architectures,  such  as: 

- point-to-point  (FTAM,  VT,  MMS) 

- store  and  forward  (MHS) 

- distributed  transactions  (TP) 

5.  to  support  data  interchange  formats  (EDI,  ODA) . 

■*  This  refers  to  the  deliverable,  stable,  text  and  is  not  to  betaken  as  a 
constraint  on  documents  to  be  considered  by  the  group. 

13.9  KEY  MANAGEMENT 


Editor's  Note:  The  outline  below  is  slightly  different  from  that 
presented  at  the  March  1990  Plenary. 

13.10  LOWER  LAYERS  SECURITY 

13.11  UPPER  LAYERS  SECURITY 

13.11.1  Presentation  Laver  Security 

13.12  MESSAGE  HANDLING  SYSTEM  SECURITY 


The  following  definitions  of  the  elements  of  security  service  are  based 
on  the  1988  CCITT  Recommendations  on  the  Message  Handling  System  (X.400). 
The  fourteen  (14)  elements  of  security  service  are  refinements  of  the 
five  (5)  primary  security  services  as  defined  in  IS  7498  Part  2 (Security 
Architecture).  The  Implementor's  Workshop  prepared  Table  13.1  that 
summarizes  where  in  the  MHS  the  element  of  security  service  may  be 
performed  (the  check  marks)  as  stated  in  the  MHS  Recommendations.  The 
Special  Interest  Group  in  Security  (SIG-  SEC)  then  examined  each  of  the 
14  elements  of  security  service  and  placed  a priority  rating  (1-5  ) next 
to  one  of  the  checkmarks  in  each  row  representing  the  priority  that 
should  be  given  for  consideration  of  standardization  and  implementation 
of  that  element  of  service.  The  SIG-SEC  reviewed  the  User  Agent  (UA)  to 
User  Agent  peer  entities  as  the  first  (perhaps  preferred)  place  to 
implement  security  and  used  the  check  mark  in  that  column  if  one  was 
present.  The  SIG-SEC  then  reviewed  the  Message  Transfer  Agent  (MTA)  to 
Message  Transfer  Agent  as  the  second  place  to  implement  security  if  it 
has  not  been  implemented  in  the  UA-UA  protocol.  Finally,  the  interface 
between  the  UA  and  the  MTA  was  investigated  for  implementing  security. 

The  Implementor's  Workshop  will  be  using  this  table  and  the  set  of 
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definitions  as  a basis  upon  which  future  work  in  MHS  security  may  be 
performed.  The  table  is  subject  to  change  during  future  meetings. 


Table  13.1  X.400  Relationship  between  Elements  of  Security  Service  and 

MHS  Components 


UA; 

User  Agent 

N- Repud. : 

Non  Repudiation 

MS; 

Message  Store 

Authen. : 

Authentication 

MTA: 

Message  Transfer  Agent 

Confiden. : 

Confidentiality 

Msg.  : 

Message 
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14.  ISO  VIRTUAL  TERMINAL  PROTOCOL 


Editor's  Note:  References  to  Stable  Agreements  in  this  section 

refer  to  Version  3,  Edition  2,  March  1990. 


14.1  INTRODUCTION 
See  Stable  Agreements. 

14.2.  SCOPE  AND  FIELD  OF  APPLICATION 


14.2.1  Phase  la  Agreements 

See  Stable  Agreements 


14.2.2  Phase  Ib  Agreements 

See  Stable  Agreements  regarding  Forms  profile. 

The  Scroll  profile  is  intended  to  support  line-at-a-time 
applications  and  has  colour  and  text  attribute  capabilities. 


14.2.3  Phase  II  Agreements 

See  Stable  Agreements  regarding  X.3  profile. 

The  Page  profiles  are  intended  for  applications  which  require 
page-oriented  operation. 


14.3  STATUS 


These  agreements  are  being  done  in  phases.  Below  is  the  current 
status  of  each  phase. 


14.3.1  Status  of  Phase  la 

The  Phase  la  Agreements,  which  include  the  profiles  for  Telnet 
and  Transparent  operation,  are  complete  and  were  stabilized  in 
May,  1988.  See  Stable  Agreements. 
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14.3.2  Status  of  Phase  Ib 


The  Forms  profile  of  Phase  lb  was  stabilized  in  December,  1988. 
Alignment  with  EWOS  Forms  profile  was  achieved  in  September, 
1989.  See  Stable  Agreements. 

14.3.3  Status  of  Phase  II 


The  Phase  II  agreements  include  profiles  for  Scroll,  X.3  and 
Page  operations  and  will  be  completed  at  an  unspecified  future 
date,  except  for  X.3,  as  mentioned  below. 

The  X.3  profile  was  stabilized  in  December,  1989.  See  Stable 
Agreements . 

It  is  intended  that  Phase  II  agreements  be  compatible  with  Phase 
I agreements . 

14.4  ERRATA 


14.5  CONFORMANCE 


See  Stable  Agreements. 


14.6  PROTOCOL 

See  Stable  Agreements. 


14,7  OIW  REGISTERED  CONTROL  OBJECTS 


14.7.1  Sequenced  Application  (SA) 

See  Stable  Agreements. 


14.7.2  Unseouenced  Application  (UA) 

See  Stable  Agreements. 
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14.7.3  Sequenced  Terminal  (ST) 

See  Stable  Agreements. 

14.7.4  Unsequenced  Terminal  (UT) 

See  Stable  Agreements. 


14.7.5  Termination  Conditions  CO  (TO 

This  CO  is  an  instance  of  the  standard  type  TCCO,  as  defined  in 
ISO  9040.  It  is  initially  designed  for  use  with  the  OIW  Scroll 
VT  profile,  though  as  a registered  CO  it  is  available  for  use  by 
other  VT  profiles. 

In  addition  to  the  three  standardized  data  elements,  it  provides 
a definition  and  update  syntax  for  further  types  of  Termination 
Condition.  Each  additional  type  is  available  for  use  in 
additional  data  elements  of  the  CO.  The  number  and  type  of  such 
additional  data  elements  is  defined  in  the  profile  using  this  CO 


14.7.5.1  Entry  Number 

To  be  supplied  by  the  Registration  Authority. 

14.7.5.2  Name  of  Sponsoring  Body 

NIST/OSI  Workshop  for  Implementors  of  OSI,  VTSIG. 

14.7.5.3  Date 

The  date  of  submission  of  this  proposal  is  September  15, 

1989. 

14.7.5.4  Identifier 

oiw-vt-co- tcco- tc  OBJECT  IDENTIFIER  : := 

{ oiw-vt-co- tcco  tc(0)  ) 

14.7.5.5  Descriptor  Value 

"OIW  VT  CO  for  Termination  Conditions" 
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14.7.5,6 CO  VTE-parameters 


CO-structure  = , *(not  defined  in  this  registration, 

see  note  1 in  14.7.5.8)* 

CO-priority  = "normal" 

{ 

CO-element- id  = 1,  *( termination  length)* 

CO-category  = "integer", 
co-size  = 65535  } , 


{ 

CO-element-id  = 2,  *(time-out  mantissa)* 
CO-category  = "integer", 

CO-size  = 65535  } , 


{ 

CO-element-id  = 3,  *(time-out  exponent)* 

CO-category  = "integer", 

CO-size  = 65535  } , 

*(the  following  represents  possibly  multiple  invocations  of 
a generic  data  element  type,  according  to  the  value  of  CO- 
structure  for  the  instance  of  this  CO.  )* 

FOR  N=4  to  CO-structure 


{ 

CO-element-id  = N,  *(acts  as  integer  identifier  for 

the  events  in  this  element)* 
CO-category  = "transparent", 

CO-size  = *(not  defined  in  this  registration,  see 
note  2 in  14.7.5.8)*  } 


14.7.5.7 CO  Values . Semantic  and  Update  Syntax 

The  value  fields  for  data  elements  1,2  and  3 are  defined  in 
ISO  9040. 


The  value  field  for  each  additional  data  element  is  defined 
by  the  following  ASN.l  construct  which  also  defines  the 
update  syntax. 


TermCondList 


::=  SEQUENCE  OF  CHOICE  { 


void 

x3ForwardingCond 
stEventList  [2] 

anySlTJpdate  [3] 

stEventMasks 
dOChars  [ 5 ] 


[0]  IMPLICIT  NULL, 

[1]  IMPLICIT  INTEGER, 
IMPLICIT  Range, 

IMPLICIT  NULL, 

[4]  IMPLICIT  MaskValues, 
IMPLICIT  DOCharacters  } 


Range  : :=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  LogEvent, 

[2]  IMPLICIT  LogEvent  OPTIONAL  ) 
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--  each  pair  represents  an  interval  of  values  as  defined  for 
--  the  value  field  of  CO  ST,  see  14.7.3.7.  The  second  value 
--  in  each  pair  shall  not  be  smaller  than  the  first  value. 

--  If  the  second  value  is  omitted,  the  interval  contains  -- 
only  the  specified  first  value. 

LogEvent  : :=  INTEGER 

--  values  as  defined  for  value  field  of  CO  ST,  see  14.7.3.7. 

MaskValues  : :=  SEQUENCE  OF  SEQUENCE  { 

mask  [1]  IMPLICIT  LogEvent, 

value  [2]  IMPLICIT  LogEvent  ) 

DOCharacters  : :=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  Repref, 

[2]  IMPLICIT  INTEGER, 

[3]  IMPLICIT  INTEGER  OPTIONAL  } 

Repref  : INTEGER 

--  index  to  the  list  of  repertoires  for  the  Display  Object 


14.7.5.8  Additional  Information 

Note  1:  The  value  of  CO- structure  is  defined  in  the 
profile  to  be  the  number  of  types  of 
termination  conditions  available  for  use  within 
the  profile. 

Note  2:  The  value  of  CO- size  for  each  additional  data 
element  of  this  CO  must  be  defined  within  the 
profile  definition  which  uses  those  additional 
termination  conditions. 

14.7.5.9  Usage 

Defined  in  profile. 


14,8  OIW  DEFINED  VTE-PROFILES 


14.8.1  Telnet  Profile 
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See  Stable  Agreements. 

14.8.2  Transparent  Profile 

See  Stable  Agreements . 


14.8.3  Forms  Profile 

See  Stable  Agreements. 

Proposed  Definitive  Note  7s  to  be  added  to  14.8.3.6.1  of  the 
Forms  Profile  in  the  Stable  Agreements: 

The  real  cursor  position  associated  with  the  completion  of 
the  terminal  user's  input  is,  in  many  cases,  used  to  convey 
information  to  the  terminal  user's  application.  As  a 
result,  when  the  terminal  VT-user  relinquishes  WAVAR,  this 
cursor  position  must  be  reported  to  the  application  VT-user 

When  the  completion  of  the  terminal  user's  input  is 
associated  with  a field,  this  cursor  position  is  reported 
via  a CCO  CO-update. 

When  the  completion  of  the  terminal  user's  input  is  not 
associated  with  a field  (only  possible  when  the  value  for 
the  VTE-parameter  is  "allowed”),  this  cursor  position  is 
reported  via  an  appropriate  implicit  or  explicit  addressing 
operation. 


14.8.4  X3  Profile 


See  Stable  Agreements. 


14.8.5  Scroll  Profile 


OIW  VTE-Profile  Scroll-1989  (rl , r2 , . . . r9) 

14.8.5.1 Introduction 


This  Scrolling  A-mode  VTE-profile  is  designed  to  support 
line-at-a- time  interactions  between  a terminal  and  a host 
system,  the  type  of  operation  t3rpified  by  operating  system 
command  entry. 

Scrolling  is  bi-directional,  forward  and  backward. 
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The  profile  also  provides  a facility  for  switching  local 
echo  "on"  or  "off". 

This  VTE-Profile  supports  what  is  often  referred  to  as 
"tjrpe -ahead" , so  input  from  the  terminal  user  is  available 
to  the  host  application  as  soon  as  the  application  is  ready 
for  input,  thus  providing  efficiency  by  minimizing 
communication  delays. 

This  VTE-profile  supports  the  definition  of  "input" 
termination  events  by  the  "Application  VT-user"  so  the 
application  can  specify  what  events  will  cause  "input"  data 
to  be  forwarded  to  the  "Application  VT-user". 


14.8.5.2  Association  Requirements 

14.8.5.2.1  Functional  Units 

The  Urgent  Data  Functional  Unit  is  optional,  and  will 
be  used  if  available. 


14.8.5.2.2  Mode 


This  profile  operates  in  A-mode. 


14.8.5.3 Profile  Body 

Display-objects  = 

{ 

{ 

display-object-name  = DOA, 

DO-access  = prof ile-argument-rl , 
dimension  = "two", 
x-dimension  = 

{ 

x-bound  = prof ile-argument-r2 , 
x-addressing  = "no-constraint", 
x-absolute  = "no", 
x-window  = x-bound 

). 

y-dimension  = 

{ 

y-bound  = "unbounded" , 
y-addressing  = "no-constraint", 
y-absolute  = "no", 
y-window  = prof ile-argument-rlO 
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), 


erasure-capability  = "yes", 

*(  repertoire-capability  is  implied  by  the  number  of 
occurrences  of  profile-argument-r4  )* 

repertoire-assignment  = prof  ile-argiament-r4 , 

DO-emphasis  = prof ile-argument-r5 , 


foreground-colour-capability  = 

profile-argument-r6 , 
foreground-colour-assignment  = 

prof ile-argument-r7 , 
background-colour-capability  = 

prof ile-argument- r6 , 
background-colour-assignment  = 

prof ile-argument- r8 

}, 

{ 

display-object-name  = DOB, 

DO-access  = opposite  of  prof ile-argument-rl , 
dimension  = "two", 

X- dimens ion  = 


x-bound  = prof ile-argument-r2 , 
x-addressing  = "no-constraint", 
x-absolute  = "no", 
x-window  = x-bound 


), 

y- dimens ion  = 

{ 

y-bound  = "unbounded" , 
y-addressing  = "higher  only", 
y- absolute  = "no" , 
y- window  = 1 

}, 

erasure  capability  = "yes", 


*(  repertoire-capability  is  implied  by  the  number  of 
occurrences  of  prof ile-argument-r4  )* 


repertoire-assignment  = prof ile-argument -r4 , 


DO-emphasis  = prof ile-argument-r5 , 


foreground-colour-capability  = 

profile-argument-r6 , 
foreground-colour-assignment  = 
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prof ile-argument-r7 , 
background-colour-capability  = 

prof ile-argument-rS , 
background-colour-assignment  = 

profile- argument -r8 


). 


Control- 

{ 

{ 

CO- 
CO- 
CO- 
CO 
CO- 
CO- 
CO- 
), 
IF 
{ 

CO 

CO 

CO 

CO 

CO 

CO 


objects  = 


name  = E,  *( standard  Echo  CO) 

type -identifier  = vt-b-sco-echo , 
access  = profile-argument-rl , 

priority  = "normal", 

trigger  = "selected", 

category  = "boolean", 

size  = 1 


), 


1-9  = "TE"  THEN 

name  = TE,  *(Termination  Event  CO)* 

type- identifier  = vt-b-sco- tco , 

access  = opposite  of  profile-argument-rl, 

priority  = "normal", 

trigger  = "selected", 

category  = "integer" 


{ 

CO-name  = SA,  *(NIST  Registered  CO)* 

CO- type- identifier  = nist-vt-co-misc-sa, 
CO-access  ^ ^ -i 

CO-priority 
CO- trigger 


CO-category 

CO-size 

). 


= profile-argument-rl, 
= "normal", 

= "not  selected", 

= "integer", 

= 65535 


{ 

CO-name  = UA,  *(NIST  Registered  CO)* 

CO- t3^e- identifier  = nist-vt-co-misc-ua , 
CO-access  = profile-argument-rl, 

CO-priority  = "urgent", 

CO-category  = "integer", 

co-size  = 65535 

}. 


CO-name 


= ST,  *(NIST  Registered  CO)* 
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CO- type-identifier  = nist-vt-co-misc-st , 

CO-access  = opposite  of  prof ile-argument-rl , 

CO-priority  = "normal", 

CO-category  = "integer", 

co-size  = 65535 

). 


{ 

co-name  = UT,  *(NIST  Registered  CO)* 

CO- type-identifier  = nist-vt-co-misc-ut , 


= opposite  of  profile-argument-rl , 
= "urgent" , 

= "integer", 

= 65535 


CO-access 
CO-priority 
CO-category 
CO-size 
), 

{ 

CO -name 

CO- type- identifier  = nist-vt-co- tcco- tc , 


= TC,  *(Termination  conditions  CO)* 


CO -structure 

CO-access 

CO-priority 


= N,  *(  defined  with  TCCO)* 
= profile-argument-rl, 
"normal" , 


CO-element-id 

CO-category 

CO-size 

{ 

CO-element-id 

CO-category 

CO-size 

{ 

CO-element-id 

CO-category 

CO-size 

{ 

CO-element-id 

CO-category 

CO-size 


= 1,  *(termination  length)* 

= "integer", 

= 65535  }, 

= 2,  *( time-out  mantissa)* 

= "integer", 

= 65535  }, 

= 3,  *(time-out  exponent)* 

= "integer", 

= 65535  ), 

= 4-N,  *(from  registered  TCCO)* 

= ??? 

• • • » 

= ???  } 


The  NIST  Workshop  VT  SIG  is  defining  this  registered  TCCO, 
This  TCCO  is  a reference  to  that  registered  control  object. 
) 

) 


Device -obj ects  = 

{ 

{ 

device-name  = DVA,  *( "output"  device  object)* 
device-default-CO-access  = profile-argument-rl, 
device-default-CO-initial-value  = l."true", 
device-display-object  = DOA, 
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device -minimum-X- array- length  = prof ile- argument- r2 , 
device -minimum-Y- array- length  = profile-argument-r3 , 
device-control-object  = {SA,UA) 

). 

{ 

device-name  = DVB,  *("input"  device  object)* 
device-default-CO-access  = opposite  of 

prof ile-argument-rl , 

device-default-CO-initial-value  = l."true", 
device-display-object  = DOB, 

device -minimum-X- array- length  = prof  lie -argxjraent-r2  , 
device-control-object  = prof ile -argument- r9 , 
device-control-object  = {ST,UT}, 
device-control-object  = TE 
} 


type-of-delivery-control  = "simple-delivery-control". 


14.8.5.4 Profile  Argument  Definitions: 

rl  - is  mandatory  and  enables  negotiation  of  which  VT-user 
has  update  access  to  display  object  DOA.  It  takes 
values  "WACI",  "WACA" . It  implies  the  asymmetric  roles 
of  the  VT-users  as  "Application  VT-user"  and  "Terminal 
VT-user".  If  the  value  for  DOA  is  "WACI",  then  the 
association  initiator  is  the  "Application  VT-user" ; if 
the  value  of  DOA  is  "WACA",  then  the  association 
initiator  is  the  "Terminal  VT-user".  This  profile 
argument  is  also  used  to  determine  which  VT-user  has 
access  to  other  VT  objects  as  described  above. 

Reference  in  the  profile  definition  to  "opposite  of 
profile-  argument-rl"  means  that  the  alternative  of  the 
two  possible  values  for  profile-  argument-rl  is  to  be 
used.  This  argument  is  identified  by  the  identifier 
for  DO-access  for  display  object  DOA. 

r2  - is  optional  and  enables  negotiation  of  a value  for 
the  VTE-parameter  x-bound  for  the  display  objects  DOA 
and  DOB.  It  takes  an  integer  value  greater  than  zero. 
This  argument  is  identified  by  the  identifier  for 
x-bound  for  display  object  DOA.  Default  is  80. 

r3  - is  optional  and  enables  the  negotiation  of  a value 

for  the  VTE-parameter  device -minimum-Y- array- length  for 
device  object  DVA.  It  takes  an  integer  value  greater 
than  zero;  if  absent,  a device  of  any  length  will  be 
satisfactory. 

Note:  Indicates  screen  length. 
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r4  - is  optional  and  provides  for  the  negotiation  of 

value(s)  for  the  VTE-parameter  repertoire - ass ignment . 

The  value  of  repertoire-capability  is  implied  by  the 
number  of  occurrences  of  this  argument.  Default  is 
specified  by  9040. 

r5  - is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  DO-emphasis.  The  default 
value  is  that  given  in  ISO  9040,  B.17.3,  Refer  to  ISO 
9040  B.17.4  for  rules  governing  the  selection  of 
non-default  values. 

r6  - is  optional  and  provides  for  the  negotiation  of 

value (s)  for  VTE- parameters  foreground-colour-capability 
and  background-colour-capability.  Default  is  8. 

r7  - is  optional  and  provides  for  the  negotiation  of  a 
value  for  VTE-parameter  foreground-colour-assignment. 
Default  is  {"white",  "black",  "red",  "cyan",  "blue", 
"yellow",  "green",  "magenta"}. 

r8  - is  optional  and  provides  for  the  negotiation  of  a 
value  for  VTE-parameter  background-colour-assignment. 
Default  is  {"black",  "white",  "cyan",  "red",  "yellow", 
"blue" , "magenta" , "green" ) . 

r9  - is  optional  and  enables  negotiation  of  a termination 
control  object.  The  value  for  this  argument  is  the 
value  of  CO-name  for  the  termination  control  object, 
i.e.  "TE" ; if  absent,  no  termination  control  is 
defined. 

rlO  - is  optional  and  provides  for  the  negotiation  of  a 

value  for  the  VTE-parameter  y-window  of  the  DOA  Display 
Object.  Default  is  24, 


14.8.5.5 Profile  Dependent  CO  Information 

This  profile  makes  use  of  five  NIST  registered  Control 
Objects,  SA,  UA,  ST,  UT  and  TCCO.  The  CO-access  in  each  CO 
is  defined  within  this  profile. 


14.8.5.6 Profile  Notes 
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1.  Only  the  first  boolean  of  the  default  control 
object  contained  in  each  device  object  is  defined. 
This  boolean  is  defined  as  the  "on/off"  switch  for 
the  device  where  the  value  ’’true"  ="on"  and  "false" 

= "off".  These  values  were  chosen  so  the  initial 
value  of  the  boolean,  "true",  means  the  device  is 
initially  "on"  and  data  to/from  the  display  objects 
is  being  mapped  to  the  device. 

2.  Only  one  boolean  is  defined  in  the  standard  echo 
control  object,  E.  The  semantics  of  this  boolean 
is  defined  such  that  "false"  means  "local  echo  off" 
and  "true"  means  "local  echo  on";  these  values  were 
chosen  so  echoing  is  initially  "off"  (which  would 
provide  security  when  a password  is  entered  at  the 
start  of  a terminal  session) . 


14.8.5.6,2  Informative  Notes 

1.  This  profile  models  a scrolling  device  which  is 
capable  of  scrolling  both  forwards  and  backwards. 

The  display  pointer  may  be  moved  backwards  to 
modify  earlier  lines.  A typical  use  for  this 
profile  is  for  applications  where  type-ahead  may  be 
advantageous  and  control  over  local  echo  "on"/"off" 
is  required,  e.g.  the  type  of  application  where  a 
conventional  teletypewriter  device 
or ' teletype-compatible ' video  device  having  'full 
duplex' capability  is  often  used.  Display  object  DOA 
referred  to  above  is  typically  mapped  to  the  display 
or  printing  device  and  display  object  DOB  is 
typically  mapped  to  the  keyboard. 

2,  Use  of  A-mode  enables  "typed- ahead" into  display 
object  DOB,  and  such  updates  can  be  delivered 
immediately  to  the  peer  VT-user,  potentially 
reducing  transmission  delays.  Such  delivery  will 
be  forced,  and  marked,  by  a termination  condition 
or  a VT-DELIVER.  Type-ahead  is  at  the  discretion 
of  the  terminal  user. 

3.  Display  object  DOB  has  an  unbounded  y-dimension  so 
as  to  provide  a blank  line  for  each  new  line 
entered. 

4.  Line-at-a- time  forward  scrolling  is  mapped  onto  an 
update -window  (value  zero)  which  allows  NO  backward 
updates  to  preceding  lines  (x-arrays) . The 
device-mlnimum-Y-array-length  negotiated  by 
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prof ile- argument- r3  can  be  used  to  indicate  the 
number  of  lines  (x-arrays)  which  should  remain 
visible  to  the  human  terminal  user  although 
specifically  NOT  available  for  update. 

5.  The  ability  to  switch  local  echo  "on"  or  "off"  is 
always  present;  the  ECHO  control  object  is  used  for 
this  purpose . 

14.8.5.7 Specific  Conformance  Requirements 

None . 
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14.9 APPENDIX  A 


See  Stable  Agreements. 
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14.10  APPENDIX  B - 

CLARIFICATIONS 

14.10.1  Defaults 

See  Stable  Agreements 
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14.11  APPENDIX  C - OBJECT  IDENTIFIERS 


See  Stable  Agreements  for  Object  Identifiers  assigned  to  objects  in 
the  Stable  Agreements.  Object  Identifiers  below  have  been  assigned 
to  objects  for  which  work  is  still  in  progress. 

Profiles  defined  by  OIW  VT  SIG: 

oiw-vt-pr-scroll-1989  OBJECT  IDENTIFIER  : := 

{ oiw-vt-pr  scroli-1989(3)  } 


Control  Objects  defined  by  OIW  VT  SIG: 

oiw-vt-co- tcco- tc  OBJECT  IDENTIFIER  : := 

{ oiw-vt-co- tcco  tc(0)  } 
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15.  TRANSACTION  PROCESSING 


15.1  Introduction 


The  NIST/OTW  Transaction  Processing  (TP)  Sig  is  developing  implementation  agreements  for 
the  TP  model,  service  and  protocol,  ISO  10026  (parts  1,  2 and  3). 

A transaction,  as  defined  in  ISO  10026,  is  a set  of  related  operations  characterized  by  the  ACID 
properties.  The  ACID  properties  are: 

Aromiciry:  a property  of  a set  of  related  operations  such  that  the  operations  are  either  all 
performed,  or  none  of  them  are  performed. 

Consistency:  a property  of  a set  of  related  operations  such  that  the  effect  of  the  operations 
are  performed  accurately,  correctly,  and  with  validity,  with  respect  to  application 
semantics.  Bound  data  is  moved  from  one  consistent  state  to  another  consistent  state. 

Isolation:  a property  of  a set  of  related  operations  such  that  the  partial  results  of  the 
operations  are  not  accessible,  except  by  operations  of  the  set. 

Durability:  a property  of  a completed  set  of  related  operations  such  that  all  the  effects  of 
the  operation  are  not  altered  by  any  sort  of  failure. 

15.2  Scope 

These  agreements  will  address  the  following  areas 

1.  Specification  of  functional  unit  profiles: 

A.  Kernel 

B.  Polarized  Control 

C.  Shared  Control 

D.  Handshake 

E.  Commit 

F.  Unchained  Transactions 

2.  Agreements  covering  TP  services  and  generation  of  TP  protocol. 

3.  Agreements  covering  the  use  of  the  following  OSI  services  by  TP: 

A.  ACSE  for  association  management 

B.  CCR  for  support  of  provider  supported  ACID  properties 

C.  Presentation  service 

D.  Directory  services 
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4.  Agreements  with  regard  to  implementation  issues  not  specified  in  ISO  10026. 

5.  Statement  of  requirements  to  meet  conformance  to  the  agreements. 

6.  Additionally,  the  following  interoperability  issues  will  be  addressed: 

A.  TP  usage  by  other  OSI  standards 

B.  Application  context 

C.  Security 

15.3  SPECIFICATION  OF  FLINCTIQNAL  UNITS 

15.3.1  FUNCTIONAL  UNITS 

Kernel 

Polarized  Control 
Shared  Control 
Handshake 
Commit 

Unchained  Transactions 

15.3.2  COMBINATIONS  OF  FUNCTIONAL  UNITS 

Application  Transactions 

Unchained  Provider-supported  Transactions 

Chained  Provider-supported  Transactions 

15.4  TP  USE  OF  OSI  SERVICES 

15.4.1  ACSE  - ASSOCIATION  MANAGEMENT 

15.4.2  CCR  - PROVIDER  ACID  PROPERTIES 

15.4.3  PRESENTATION  SERVICES 

15.4.4  DIRECTORY  SERVICES 
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15.5  IMPLEMENTATIONS  ISSUES  NOT  SPECIFIED  IN  TSO  10026 

15.5.1  APPLICATION  CONTEXT 

15.5.2  SECURITY 

15.5.3  RECOMMENDED  PRACTICES 

15.6  CONFORMANCE  STATEMENT 

15.7  OSI  TRANSACTION  PROCESSING  PROTOCOL  AGREEMENTS 


The  tables , below  detail  the  requirements  included  in  the  NIST  OSI  TP  Implementation 
Agreement.  The  tables  present  the  following  information: 

o Optional  and  Mandatory  PDU  fields  and  their  ranges 
o Optional  and  Mandatory  ASE  service  primitive  parameters  and  their  ranges 

All  the  tables  are  written  in  a PICS-like  format.  Each  row  contains  a field  or  parameter  followed 
by  the  standard’s  requirements  for  that  item  and  then  NIST’s  (Implementation  Agreement) 
requirements.  For  PDU  fields  and  service  parameters,  additional  columns  containing  a range 
and  notes  are  included. 

Unless  otherwise  noted,  the  following  column  descriptions  and  keys  apply  to  all  tables: 

FIELD/PARAMETER:  The  particular  standard-defined  field  or  parameter  being  described. 

STND:  The  Transaction  Processing  standard’s  (ISO  10026)  requirements  for  the 

item.  This  field  will  have  one  of  the  following  values;  their  meaning  is 
defined  by  the  international  standard. 

M:  Mandatory 
C:  Conditional 
O:  Optional 
NU:  Not  Used 

NIST:  This  implementation  agreement’s  requirements  for  the  item.  This  field  will  have 

one  of  the  following  values;  their  meaning  is  defined  by  the  implementation 
agreement. 

Y:  Supported,  this  is  a mandatory  or  optional  feature  in  the  base  standard. 

Its  syntax  and  semantics  shall  be  implemented  as  specified  in  the  base 
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standard  or  the  TP  agreements  by  all  implementations  claiming 
conformance  to  the  profile.  It  is  not  a requirement  that  the  feature  shall 
be  used  in  ail  instances  of  communications,  unless  mandated  by  the  base 
standard  or  stated  otherwise  in  the  TP  agreement.  Fully  supported 
attributes  will  conform  to  at  least  the  minimum  range  of  values  as  defined 
in  ISO  10026-3,  unless  stated  otherwise  in  the  TP  agreement.  Conformant 
implementations  supporting  optional  features  will  be  able  to  interoperate 
with  those  implementations  which  do  not  support  the  feature.  The  support 
of  a feature  can  depend  on  the  support  of  a class  of  features  to  which  it 
belongs,  e.g.  parameter  in  a PDU,  a PDU  in  a functional  unit. 

O:  Optionally  supported,  is  left  to  the  implementation  as  to  whether  this 

feature  is  supported.  If  a parameter  is  optionally  supported,  then  the 
syntax  shall  be  supported,  but  it  is  left  to  each  implementation  whether 
the  semantics  are  supported.  The  receiver  of  an  unsupported  optional 
parameter  which  is  not  subject  to  negotiation  shall,  at  least,  inform  the 
sender  by  informative  diagnostic, and  interoperability  will  not  be  affected. 

NIST  RANGE:  The  allowable  range  of  values  for  this  parameter. 

SOURCE:  Who  supplies  data  for  the  parameter.  This  field  will  have  one  of  the 

following  values: 

TPPM:  Transaction  Processing  Protocol  Machine 
REQ:  Requesting  TPSUI 

SINK:  Who  uses  the  parameter.  This  field  will  have  one  of  the  following  values: 

TPPM:  Transaction  Processing  Protocol  Machine 
IND:  Receiving  TPSUI 
REQ:  Requesting  TPSUI 

NOTES:  Any  additional  comments  applying  to  the  parameter. 
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TP-BEGIN-DIALOGUE-RI 


Sending,  to  begin  a dialogue 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Initiating-TPSU-Title 

0 

0 

TPPM 

0..2**31-I 

Recipient-TPS  U -Title 

C 

Y 

Req 

0..2**31-1 

Selected-Functionai- 

Units 

c 

Y 

Req 

2 

Commit 

0 

0 

Polarized-Control 

o 

O 

Handshake 

0 

o 

Unchained- 

Transactions 

0 

0 

Initiai-Coordination- 

Level 

c 

Y 

Req 

Invocation-data 

0 

0 

Req 

1 

Dialogue/  Channel- 
Identifier 

M 

Y 

TPPM 

0..2»*31-1 

Sending,  to  begin  a TP  channel 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Dialogue/Channel- 

Identifier 

M 

Y 

TPPM 

0..2**31-1 

Channel-utilization 

C 

Y 

TPPM 
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March  1990  (Working) 


Receiving,  to  begin  a dialogue 


FIELD 

STND 

NIST 

SINK. 

NIST 

RANGE 

NOTES 

Initiating-TPSU-Title 

O 

Y 

Ind 

Recipien  t-TPSU-T  itle 

c 

Y 

Ind 

0..2=^’*‘31-i 

Selected-Functional- 

Units 

c 

Y 

Ind 

2 

Commit 

0 

O 

Polarized-Control 

0 

0 

Handshake 

0 

0 

Unchained- 

Transactions 

o 

O 

Initial-Coordination- 

Level 

c 

Y 

Ind 

Invocation-data 

o 

O 

Ind 

1 

Dialogue/ Channel- 
Identifier 

M 

Y 

TPPM 

0..2**31-1 

Receiving,  to  begin  a TP  channel 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Dialogue/Channel- 

Identifier 

M 

Y 

TPPM 

0..2**31-1 

Channel-Utilization 

C 

Y 

TPPM 

Note:  1.  May  need  to  determine  limits  on  the  amount  and  type  of  data  passed  in  this 

manner. 

2.  See  section  "Support  of  Functional  Units"  for  minimum  valid  combinations  of 
functional  units. 
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March  1990  (Working) 


TP-BEGIN-DIALOGUE-RC 


Sending 


FIELD 

SEND 

NIST 

SOURCE 

NIST 

RANGE 

:n 

NOTES 

Dialogue/Channel- 

Identifler 

M 

Y 

TPPM 

0..2**31-1 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Diaiogue/Channel- 

Identifier 

M 

Y 

TPPM 

0..2**31-1 

TP-REJECT-RI 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

TPPM 

Diagnostic 

C 

Y 

1,  4 

User-data 

O 

O 

Req 

2,  3 

Dialogue/Channel- 

Identifier 

M 

Y 

TPPM 

0..2**31-1 
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March  1990  (Working) 


TP-REJECT-Rl,  Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

TPPM 

Diagnostic 

C 

Y 

1,4 

User-data 

O 

0 

Req 

2,  3 

Dialogue/  Channel- 
Identifier 

M 

Y 

TPPM 

0..2**31-1 

Note:  1.  User/Provider  division  of  values  is  unclear  in  standard’s  ASN.  1. 

2.  May  need  to  determine  limits  on  the  amount  and  type  of  data  passed  in  this 
manner. 

3.  Parameter  is  present  on  provider  rejects. 

4.  Parameter  is  present  on  user  rejects. 


TP-BID-RI 
No  parameters 


TP-BID-RC 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Result 

M 

Y 

TPPM 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Result 

M 

Y 

TPPM 
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March  1990 


(Working) 


TP-END-DIALOGUE-RI 

No  parameters 

TP-U-ERRQR-RI 

No  parameters 

TP-U-ERROR-RC 

No  parameters 


TP-P-ERROR-RI 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Diagnostic 

M 

Y 

TPPM 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Diagnostic 

M 

Y 

Ind 

TP-ABORT-RI 

Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

TPPM 

Diagnostics 

C 

Y 

TPPM 

1,4 
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User-data 

C 

O 

Req 

2,  3 

TP-ABORT-RI,  Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

Ind 

Diagnostics 

C 

Y 

Ind 

1,  4 

User-data 

C 

0 

Ind 

2,  3 

Note:  1.  May  want  to  specify  meanings  for  the  reason  codes,  Permanent  and  Transient 

failure. 

2.  May  need  to  determine  limits  on  the  amount  and  type  of  data  passed  in  this 
manner.  Text  says  parm  is  optional,  ASN.l  says  mandatory. 

3.  Parameter  is  present  on  provider  abort. 

4.  Parameter  is  present  on  user  abort. 

TP-REOUEST-CONTROL-RI 

No  parameters 


TP-GRANT-CONTROL-RI 

No  parameters 


TP-HANDSHAKE-RI 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

TPPM 

Confirmation 

C 

Y 

Req 

TP-HANDSHAKE-RI,  Receiving 
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FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Type 

M 

Y 

TPPM 

Confirmation 

C 

Y 

TPPM 

1 

Note:  1 . Parameter  is  present  only  on  handshake  when  Shared  Control  functional  unit  is 

active. 


TP-HANDSHAKE-RC 

No  parameters 


TP-HANDSHAKE-AND-GRANT-CONTROL-RI 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Confirmation 

M 

Y 

Req 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Confirmation 

M 

Y 

TPPM 

TP-HANDSHAKE-AND-GRANT-CONTROL-RC 

No  parameters 
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TP-DEFER-RI 

Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

End-dialogue 

O 

Y 

TPPM 

1 

Grant-control 

O 

Y 

TPPM 

1 

Next-Transaction 

0 

Y 

TPPM 

1 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

End-dialogue 

O 

Y 

TPPM 

1 

Grant-control 

0 

Y 

TPPM 

1 

Next-Transaction 

O 

Y 

TPPM 

I 

Note:  1 . The  field  is  mandatory  only  if  requirexl  by  supported  functional  units,  else  it  is 

not  used. 


TP-PREPARE-RI 

Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Data-permitted 

O 

Req 
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TP-PREPARE-RI , Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Data-permitted 

0 

Ind 

TP-UNCHAIN-RI 

No  parameters 

TP-BEGIN-TRANSACTION-RI 


Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Chain 

M 

Y 

TPPM 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Chain 

M 

Y 

TPPM 
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March  1990  (Working) 


TP-ASSOCIATIOM-ESTABLISHMENT-RI 

Sending 


FIELD 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Protocol  Version 

M 

Y 

TPPM 

Contention  winner 
assignment 

M 

Y 

TPPM 

Bid-Mandatory 

M 

Y 

TPPM 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Protocol  Version 

M 

Y 

TPPM 

Contention  winner 
assignment 

M 

Y 

TPPM 

Bid-Mandatory 

M 

Y 

TPPM 

TP-ASSOCIATION-ESTABLISHMENT-RC 


Sending 


"""1 

FIELD 

, , . 

STND 

NIST 

SOURCE 

NIST 

RANGE 

NOTES 

Protocol  Version 

M 

Y 

TPPM 

Receiving 


FIELD 

STND 

NIST 

SINK 

NIST 

RANGE 

NOTES 

Protocol  Version 

M 

Y 

TPPM 
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March  1990  (Working) 


ACSE  SERVICE  PARAMETERS 

This  section  shows  TP’s  use  of  ACSE  services  and  parameters. 


A-ASSOCIATE 
Sending  (Request /Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Mode 

M 

Y 

Application  Context 
Name 

M 

Y 

Calling  AP  Title 

M(A) 

Calling  AE  Qualifier 

M(A) 

Calling  AP  Invocation 
Identifier 

M 

Calling  AE  Invocation 
Identifier 

M 

Called  AP  Title 

C(A) 

Called  AE  Qualifier 

C(A) 

Called  AP  Invocation 
Identifier 

C(B) 

Called  AE  Invocation 
Identifier 

C(B) 

Responding  AP  Title 

M(A) 

Responding  AE 

Qualifier 

M(A) 

Responding  AP 
Invocation 

Identifier 

M(A) 

, 
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PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Responding  AE 
Invocation 

Identifier 

M(A) 

User  Information 

M 

Y 

Result 

M 

Y 

Diagnostic 

0 

O 

Calling  Presentation 
Address 

M 

Y 

Called  Presentation 
Address 

M 

Y 

Responding 

Presentation  Address 

O 

O 

Presentation  Context 
Definition  List 

M 

Y 

Presentation  Context 
Definition  Result  List 

O 

O 

Default  Presentation 
Context  Name 

0 

NU 

Default  Presentation 
Context  Result 

0 

NU 

Quality  of  Service 

M 

Y 

Presentation 

Requirements 

M 

Y 

Kernel  only 

Session  Requirements 

M 

Y 

Kernel  + Full 
Duplex  -f- 
CCR  requirements 
(if  used) 

15-16 


{ 


March  1990  (Working) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Initial  Synchronization 
point  Serial  Number 

M(A) 

Initial  Assignment  of 
Tokens 

M(A) 

Session-Connection 

Identifier 

NU 

NU 

Note:  (A)  Only  if  CCR  is  used,  else  parameter  is  a user  option 

(B)  Parameter  becomes  mandatory  if  the  association  is  being  established  for 


A-ASSOCIATE 

Receiving  (Indication/ Confirmation) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Mode 

M 

Y 

Application  Context 
Name 

M 

Y 

Calling  AP  Title 

M(A) 

Calling  AE  Qualifier 

M(A) 

Calling  AP  Invocation 
Identifier 

M 

Calling  AE  Invocation 
Identifier 

M 

Called  AP  Title 

C(A) 

Called  AE  Qualifier 

C(A) 
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PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Called  AP  Invocation 
Identifier 

C(B) 

Called  AE  Invocation 
Identifier 

C(B) 

Responding  AP  Title 

M(A) 

Responding  AE 

Qualifier 

M(A) 

Responding  AP 
Invocation 

Identifier 

M(A) 

Responding  AE 
Invocation 

Identifier 

M(A) 

User  Information 

M 

Y 

Result 

M 

Y 

Result  Source 

M 

Y 

Diagnostic 

O 

O 

Calling  Presentation 
Address 

M 

Y 

Called  Presentation 
Address 

M 

Y 

Responding 

Presentation  Address 

0 

0 
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March  1990  (Working) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Presentation  Context 
Definition 

List 

M 

Y 

Presentation  Context 
Definition 

Result  List 

O 

Y 

Default  Presentation 
Context  Name 

0 

NU 

Default  Presentation 
Context 

Result 

0 

NU 

Quality  of  Service 

M 

Y 

Presentation 

Requirements 

M 

Y 

Kernel  only 

Session  Requirements 

M 

Y 

Kernel  + Full 
Duplex  -1- 
CCR  requirements 
(if  used) 

Initial  Synchronization 
Point  Serial  Number 

M(A) 

Initial  Assignment  of 
Tokens 

M(A) 

Session-Connection 

Identifier 

NU 

NU 

Note:  (A)  Only  if  CCR  is  used,  else  parameter  is  a user  option 

(B)  Parameter  becomes  mandatory  if  the  association  is  being  established  for 
recovery  purposes  (channels) 
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A-RELEASE 

Sending  (Request /Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Reason 

NU 

NU 

User  information 

NU 

NU 

Result 

M 

Y 

Recei ving  (Indication/Confi mation ) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Reason 

NU 

NU 

User  information 

NU 

NU 

Result 

M 

Y 

A-ABORT 


Sending  (Request) 


PARAMETER 

STND 

NIST 

■ 

NIST  RANGE 

NOTES 

User  Information 

NU 

NU 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Abort  Source 

M 

Y 

User  information 

NU 

NU 
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A-P-ABORT 
Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Provider  Reason 

0 

0 

PRESENTATION  SERVICE  PARAMETERS 

This  section  shows  TP’s  use  of  Presentation  services  and  parameters. 


P-TOKEN-PLEASE 

Sending  (Request) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Tokens 

1 

User-data 

NU 

NU 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Tokens 

1 

User-data 

NU 

NU 

Note:  1 . Why  is  there  an  inconsistency  in  the  token  parameter  of  P-Token-Please  and 

P-Token-Give, 
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P-TOKEN-GIVE 

Sending  (Request) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Tokens 

M 

Y 

- 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Tokens 

M 

1 

P-DATA 

Sending  (Request) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

M 

Y 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

M 

Y 
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March  1990  (Working) 


CCR  SERVICE  PARAMETERS 

This  section  shows  TP’s  use  of  CCR  services  and  parameters. 
C-BEGIN 


Sending  (Request /Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Atomic  Action  Id.- 
Master’s  Name 

M 

Y 

Atomic  Action  Id.- 
Suffix 

M 

Y 

1 

Branch  Id. -Superior’s 
Name 

M 

Y 

Branch  Id. -Suffix 

M 

Y 

1 

User  Data 

C 

Y 

1 

Receiving  (Indication/Confirmation) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOl'ES 

Atomic  Action  Id.- 
Master’s  Name 

M 

Y 

Atomic  Action  Id.- 
Suffix 

M 

Y 

1 

Branch  Id. -Superior’s 
Name 

M 

Y 

Branch  Id, -Suffix 

M 

Y 

1 

User  Data 

C 

Y 

Note:  1 . Must  decide  which  CCR  ASN.  1 Choice  to  use 
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C-PREPARE 
Sending  (Request) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 

C-READY 


Sending  (Request) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

NU 

NU 

Receiving  (Indication) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

NU 

NU 

C-COMMIT 


Sending  (Request/Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 
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C-COMMIT,  Receiving  (Indication/Confirmation) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 

C-ROLLBACK 
Sending  (Request/Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 

Recei  ving  (Indication/Confi  rniarion ) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

User-data 

C 

Y 

C-RECOVER 


Sending  (Request/Response) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Recovery  State 

M 

Y 

Atomic  Action 

Identifier 

M 

Y 

Branch  Identifier 

M 

Y 

User-data 

C 

Y 
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C-RECOVER,  Receiving  (Indication /Confimmtion) 


PARAMETER 

STND 

NIST 

NIST  RANGE 

NOTES 

Recovery  State 

M 

Y 

Atomic  Action 

Identifier 

M 

Y 

Branch  Identifier 

M 

Y 

User-data 

C 

Y 

Editor’s  Note:  Some  minoir  diffferences  exist  with  previous  material 
in  the  Working  Document. 
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16.  OFFICE  DOCUMENT  ARCHITECTURE 


Editor's  Note:  For  current  Stable  ODA  Agreements  as  of  June  1990, 
consult  the  aligned  section  of  the  Stable 
Implementation  Agreements  Document,  Version  3, 
Edition  2,  March  1990, 

There  is  international  alignment  work  progressing 
between  the  OIW,  EWOS , and  AOW  on  the  Level  3 DAP 
(based  on  Chapter  16  in  the  Stable  Document) . As 
these  alignment  changes  are  completed, 
appropriate  changes  will  be  included  in  a revised 
Chapter  16.  The  current  intention  is  to  rename 
Chapter  16  to  "Office  Document  Architecture  Level 
3 DAP." 
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17  INTRODUCTION 


This  is  the  definition  of  an  implementation  agreement  for  ODA  that  is 
based  on  a document  application  profile  (DAP)  named  NIST  ODA  Level  2 DAP, 
These  agreements  will  consist  of  a document  application  profile  and  a 
generator  support  statement  (GSS) /receiver  support  statement  (RSS) 
proforma.  This  document  application  profile  is  suitable  for 
Interchanging  a document  in  formatted  form,  processable  form  or  formatted 
processable  form.  This  implementation  agreement  has  been  prepared  by 
the  ODA  Special  Interest  Group  of  the  NIST  OSI  Implementors  Workshop 
(OIW) . The  document  application  profile  portion  of  this  implementation 
agreement  is  defined  in  accordance  with  ISO  8613-1  and  CCITT  T.411  and 
follows  the  standardized  proforma  and  notation  defined  in  ISO  8613-1 
proposed  Draft  Addendum.  Section  17  through  17.8  define  the  document 
application  profile  included  in  these  agreements.  Section  17.9  defines 
the  GSS/RSS  proforma  included  in  these  agreements.  Additional  sections 
contain  informative  material  concerning  these  agreements. 

Note;  The  document  application  profile  defined  by  these  agreements  will 
be  superceded  by  the  equivalent  internationally  aligned  document 
application  profile  when  it  is  submitted  for  processing  as  an 
Internationally  Aligned  Profile  (ISP) . 

17.1  SCOPE  AND  FIEU)  OF  APPLICATION 

This  document  application  profile  specifies  interchange  formats  for  the 
transfer  of  structured  documents  between  equipment  designed  for  word  or 
document  processing.  Such  documents  may  contain  characters,  raster 
graphics  and  geometric  graphics  content. 

The  documents  supported  by  this  profile  range  from  simple  documents  to 
structured  technical  reports,  articles  and  typeset  documents  such  as 
brochures.  This  profile  provides  a comprehensive  level  of  features  for 
the  transfer  of  documents  between  these  systems. 

This  document  application  profile  describes  documents  which  can  be 
interchanged  in  the  following  form,  as  defined  in  ISO  8613: 

Formatted  form, 

Processable  form,  and 
Formatted  processable  form. 

The  architecture  level  have  matching  functionalities  so  that  the 
interchange  formats  of  a dociiment  are  convertible  from  a processable  form 
into  any  other  form. 

This  document  application  profile  is  independent  of  the  processes  carried 
out  in  an  end  system  to  create,  edit  or  reproduce  which,  for  example,  may 
be  by  means  of  communication  links  or  storage  media. 
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17.2  REFERENCES 

ISO  2022  Information  Processing  - ISO  7-bit  and  8-bit  coded  character 
sets  - Code  extension  techniques 

ISO  6937-1  Information  Processing  - Coded  character  sets  for  text 
communication  - Part  1 : General  introduction 

ISO  6937-2  Information  Processing  - Coded  character  sets  for  text 
communication  - Part  2:  Latin  alphabetic  and  non- alphabetic  graphic 
characters 


ISO  8613-1  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part  1:  Introduction 
and  General  Principles 


ISO  8613-2  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
2:  Docum.ent  Structures 

ISO  8613-4  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
4:  Document  Profile 


ISO  8613-5  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
5:  Office  Document  Interchange  Format 

ISO  8613-6  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
6:  Character  Content  Architecture 

ISO  8613-7  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
7 : Raster  Graphics  Content  Architecture 

ISO  8613-8  Information  Processing  - Text  and  Office  Systems  - Office 
Document  Architecture  (ODA)  and  Interchange  Format  - Part 
8:  Geometric  Graphics  Content  Architecture 


ISO  8613-1  PDAD  . . . "Document  Application  Profile  Proforma  and  Notation" 
(to  be  published) 

ISO  8632-1  Information  Processing  Systems  - Computer  Graphics  - Metafile 
for  the  storage  and  transfer  of  picture  description  information  - Part  1: 
Functional  Specification 

ISO  8632-3  Information  Processing  Systems  - Computer  Graphics  - Metafile 
for  the  storage  and  transfer  of  picture  description  information  - Part  3: 
Binary  Encoding 
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ISO  8859-1  Information  Processing  - 8-bit  single  byte  coded  graphic 
character  sets  - Part  1:  Latin  Alphabet  No.  1 

ISO  8859-7  Information  Processing  - 8-bit  single  byte  coded  graphic 
character  sets  - Part  7 : Latin/Greek  Alphabet 

ISO  8824  Information  Processing  Systems  - Open  Systems  Interconnection  - 
Specification  of  Abstract  Syntax  Notation  1 (ASN.l) 

ISO  8825  Information  Processing  Systems  - Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  1 
(ASN.l) 


CCITT  T.6  - Facsimile  coding  scheme  and  coding  control  functions  for 
Group  4 Facsimile  Apparatus,  1984 


CCITT  T.411  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Introduction  and  general  principles,  1988 


CCITT  T.412  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Dociament  structures,  1988 


CCITT  T.414  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Document  profile,  1988 


CCITT  T.415  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Open  document  interchange  format,  1988 


CCITT  T.416  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Character  content  architecture,  1988 

CCITT  T.417  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Raster  graphics  content  architecture,  1988 


CCITT  T.418  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Geometric  graphics  content  architecture,  1988 


CCITT  T.502  Document  Application  Profile  PM.l  for  the  interchange  of 
processable  form  documents 


NIST  . . . Office  Document  Architecture  Level  3 DAP,  Stable  Implementation 
Agreements  for  Open  Systems  Interconnection  Protocols,  Version  2 Edition 
3,  June  1989. 


PrENV  41-509  . . . Qlll  ODA  document  application  profile  - processable  and 
formatted  documents  - basic  character  content,  October  1989. 

PrENV  41-510  . , . Q112  ODA  document  application  profile  - processable  and 
formatted  documents  - enhanced  mixed  mode,  October  1989. 
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PrENV  . . . Q113  ODA  document  application  profile  - processable  and 
formattable  document  - extended  mixed  mode  (to  be  published). 

INTAP  . , . AE-1126  ODA  document  application  profile  . . . 

PAGODA  . . . CORE- 11  ODA  document  application  profile  - processable  and 
formatted  documents  - basic  character  content  (to  be  published) 

PAGODA  . . . CORE-26  ODA  document  application  profile  - processable  and 
formatted  documents  - enhanced  mixed  mode  (to  be  published) 

PAGODA  . . . CORE-36  ODA  document  application  profile  - processable  and 
formatted  documents  - extended  mixed  mode  (to  be  published) 

17.3  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 

The  following  additional  definitions  are  applicable  to  this  document. 
Generating  Support  Statement  (GSS) 

A statement  which  states  the  range  of  support  of  an  originating  system. 
An  originating  system  generates  ODIF  data  streams.  A GSS  defines  a 
subset  of  all  possible  data  streams  supported  by  an  implementation  which 
an  origination  capability.  A GSS  is  specified  by  completing  the  GSSP 
defined  in  Annex  A of  this  document. 

Generating  Support  Statement  Proforma  (GSSP) 

A definition  of  the  conformance  requirements  of  a profile  in  terms  of  a 
list  of  requirements  for  implementations  to  originate  data  streams 
which  conform  to  the  profile.  A GSSP  defines  the  format  for  all  GSSs. 

Receiving  Support  Statement  (RSS) 

A statement  which  states  the  range  of  support  of  a receiving  system.  A 
receiving  system  interprets  ODIF  data  streams.  A RSS  defines  functions 
and  fall-backs  supported  by  an  implementation  with  a reception 
capability.  A RSS  is  specified  by  completing  the  RSSP  defined  in  Annex 
A of  this  document. 

Receiving  Support  Statement  Proforma  (RSSP) 

A definition  of  the  conformance  requirements  of  a profile  in  terms  of  a 
list  of  requirements,  including  fail-backs,  for  intplementations  to 
receive  data  streams  which  conform  to  the  profile.  A RSSP  defines  the 
format  for  all  RSSs. 

17.4  POSITION  OF  THIS  DAP  IN  THE  TAXONOMY  OF  REIATED  DA1»S 

There  are  several  regional  activities  involving  the  development  of  ODA 
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document  application  profiles  other  than  the  NIST  ODA  SIG.  These  include 
the  following: 

Asia-Oceania  Workshop  (AOW)  ODA  SIG 
CCITT  Study  Group  VIII,  Question  26 
European  Workshop  for  Open  Systems  ODA  EG 
Profile  Alignment  Group  for  ODA  (PAGODA) 

17.4.1  AOW  ODA  SIG 

This  document  application  profile  is  a functional  subset  of  the  AOW  AE- 
1126  document  application  profile.  This  document  application  profile  is 
a functional  superset  of  the  AOW  AE-1111  and  AE-1116  document  application 
profiles . 

17.4.2  CCITT  SG  VIII,  Q26 

This  document  application  profile  is  expected  to  be  a functional  subset 
of  the  CCITT  "pm3"  document  application  profile.  This  document 
application  profile  is  expected  to  be  functionally  equivalent  to  the 
CCITT  "pm2"  document  application  profile.  This  document  application 
profile  is  a functional  superset  of  the  CCITT  T..‘502  Recommendation. 

17.4.3  EWOS  ODA  EG 

This  document  application  profile  is  expected  to  be  a functional  subset 
of  the  EWOS  Q113  document  application  profile.  This  document  application 
profile  is  a functional  superset  of  the  EWOS  Qlll  document  application 
profile.  This  document  application  profile  is  expected  to  be  equivalent 
to  the  EWOS  Q112  document  application  profile. 

17.4.4  NIST  ODA  SIG 

This  document  application  profile  is  a subset  of  the  NIST  Level  3 DAP. 

17.4.5  PAGODA 

There  are  three  document  application  profiles  developed  by  PAGODA  for 
submission  as  ISPs.  These  are  names  Core-11,  Core-26  and  Gore-36.  This 
document  application  profile  is  intended  to  comparable  with  the  Core-26 
document  application  profile.  This  document  application  profile  is 
intended  to  be  a superset  of  the  Core-11  document  application  profile. 
This  document  application  profile  is  intended  to  be  a subset  of  the  Core- 
36  document  application  profile. 

17.5  CONFORMANCE 
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In  order  to  conform  to  this  document  application  profile,  a data  stream 
representing  a document  must  meet  the  requirements  specified  in  subclause 

1. 

Subclause  2 specifies  the  requirements  for  implementations  that 
originate  and/or  receive  data  streams  conforming  to  this  document 
application  profile. 

17.5.1  Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that 
conform  to  these  agreements. 

The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.l 
encoding  rules  defined  in  ISO  8825, 

The  data  stream  shall  be  structured  in  accordance  with  the 
interchange  format  defined  in  clause  8 of  this  document 
application  profile. 

The  encoded  document  shall  be  structured  in  accordance  with  one 
of  the  document  architecture  classes  specified  in  clause  7 of 
this  document  application  profile.  In  addition,  the  encoded 
document  shall  contain  all  required  constituents  specified  for 
that  class  and  contain  only  constituents  permitted  or  required 
for  that  class  as  specified  in  clause  7 of  this  document 
application  profile, 

The  encoded  constituents  shall  contain  all  required  attributes  as 
specified  in  clause  7 of  this  document  application  profile. 

The  encoded  attributes  shall  have  values  within  the  range  of 
permissible  values  specified  in  clause  7 of  this  document 
application  profile, 

The  encoded  document  shall  be  structured  in  accordance  with  the 
abstract  document  architecture  defined  in  ISO  8613, 

The  encoded  document  shall  be  structured  in  accordance  with  the 
characteristics  defined  in  clause  6 of  this  document  application 
profile . 

17.5.2  Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming 
conformance  to  this  document  application  profile. 

An  implementation  claiming  to  originate  and/or  receive  data  streams 
conforming  to  this  document  application  profile  must  complete  a Generator 
Support  Statement  (GSS)  and/or  Receiver  Support  Statement  (RSS)  Proforma 
as  defined  in  section  17.9  of  this  document  application  profile. 
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A conforming  receiving  implementation  must  be  capable  of  receiving  any 
data  stream  conforming  to  this  document  application  profile,  "Receiving" 
means  not  rejecting  a data  stream  conforming  to  this  document  application 
profile  and  usually,  but  not  always,  involves  recognizing  and  further 
processing  the  data  stream  elements.  The  explicit  meaning  of  "receiving" 
is  determined  by  a RSS  defined  in  accordance  with  section  17.9  of  this 
document  application  profile. 

17.6  CHARACTERISTICS  SUPPORTED  BY  THIS  DAP 

Note:  Text  corresponding  to  the  logical  and  layout  constraint  objects 
defined  in  section  17.7  will  be  defined  for  this  section. 

17.7  SPECIFICATION  OF  CONSTITUENT  CONSTRAINTS 

17.7.1  Document  profile  constraints 

17 . 7 . 1 . IMacro  definitions 

DEFINE(BASIC-CHAR-SET, "{ 

{ESC  02/08  Fi,  LSO} ; 

Designates  a version  of  ISO  646  to  GO  and  invokes  to  GL 

F]^  should  be  the  final  character  of  a version  of  ISO  646.  ASCII 
(final  character  04/02)  should  be  "Rwof"  in  the  GSS/RSS  Proforma. 

") 

DEFINE(NON-BASIC-CHAR-SET, " 

ESC  02/09  F2,  LSIR  | 

Designates  94  single  byte  set  to  Gl  and  invokes  to  GR 
ESC  02/04  02/09  F3 , LSIR  [ 

Designates  94  multi-byte  set  to  Gl  and  invokes  to  GR 
ESC  02/10  F4,  LS2R  | 

Designates  94  single  byte  set  to  G2  and  invokes  to  GR 
ESC  02/04  02/10  F5 , LS2R  | 

Designates  94  multi-byte  set  to  G2  and  invokes  to  GR 
ESG  02/11  Fg,  LS3R  | 

Designates  94  single  byte  set  to  G3  and  invokes  to  GR 
ESC  02/04  02/11  F7,  LS3R  j 

Designates  94  multi -byte  set  to  G3  and  invokes  to  GR 
ESC  02/13  Fg,  LSIR  \ 

Designates  96  single  byte  set  to  Gl  and  invokes  to  GR 
ESC  02/04  02/13  Fg , LSIR  | 

Designates  96  multi-byte  set  to  Gl  and  invokes  to  GR 
ESC  02/14  FiO,  LS2R  j 

Designates  96  single  byte  set  to  G2  and  invokes  to  GR 
ESC  02/04  02/14  F^l,  LS2R  | 

Designates  96  multi-byte  set  to  G2  and  invokes  to  GR 
ESC  02/15  ¥i2,  LS3R  | 

Designates  96  single  byte  set  to  G3  and  invokes  to  GR 
ESC  02/04  02/15  Fi3,  LS3R 
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Designates  96  multi-byte  set  to  G3  and  invokes  to  GR 


is  defined  in  the  "International  Register  of  Coded  Character  Sets 
to  be  used  with  Escape  Sequences”.  The  empty  sets  (final  character 
07/14)  should  be  designated  and  invoked  in  GR  if  there  are  no  further 
requirements  on  characters  other  than  those  designated  in  GO  set. 

") 

DEFINE (CODE-EXT-ANNOUNCERS , ” 

[ESC  02/00  05/00  j 
ESC  02/00  05/03  j 
ESC  02/00  05/05  j 
ESC  02/00  05/07  | 

ESC  02/00  05/10  I 
ESC  02/00  05/11]+ 

") 

DEFINE (BASIC -SUBREPERTOIRES , " 

2 1 

Minimal 

5 I 

Unique  characters  allocated  in  ISO  646 

8 

--  ISO  8859-1  subrepertoire  -- 

") 

DEFINE (NON- BASIC -SUBREPERTOIRES , " 

1 I 

Full 

3 ! 

Teletex 

^ I 

Videotex 

7 }, 

Western  European  Typeset 

") 

DEFINE(BASIC-PAG-DIM, " 

Common  Assured  Reproduction  Areas  (CARA) 

#horizontal{  9240 . . 39732  ) ,#A’'ertical{  12400 ..  56173 ) , | 

CARA  of  ISO  A4  and  ANSI  A portrait  <=  ISO  AO  portrait 
#horizontal{ 12400. .56173} ,#vertical{9240. . 39732} , | 

CARA  of  ISO  A4  and  ANSI  A landscape  <=  ISO  AO  landscape 
#horizontal { 9240 . . 39600 } ,#vertical { 12400 . . 52200 } , | 

CARA  of  ISO  A4  and  ANSI  A portrait  <=  ARA  ANSI  E portrait 
#horizontal{ 12400 . . 52200 ) ,#vertical{ 9240 . .39600} 

CARA  of  ISO  A4  and  ANSI  A landscape  <=  ARA  ANSI  E landscape 

") 

DEFINE(NON-BASIC-PAG-DIM, " 
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Assured  Reproduction  Areas  (ARA) 


{#horizontal{ 13200} ,#vertical( 18480} 

ARA  ISO  A3  Portrait  (279mni  x 391mn!) 
{#horizontal{  18840}  ,#vertical.{  13200}  | 

ARA  ISO  A3  Landscape  (420iiuii  x 297nim) 
{#horizontal{  12744}  ,#^7ertical{  19656 } j 
--  A_RA  ANSI  B Portrait  (10.62in  x 16.38in) 
{#horizontal{ 19656} ,#vertical{ 12744} 

ARA  ASNI  B Landscape  (16.38in  x 10.62in) 

--  Full  Page  Sizes  -- 

{#horizontal { 14031 } ,#vertlcal { 19843 } | 

ISO  A3  Portrait  (297mm  x 420mm) 
{#horizontal { 19843 } ,#vertical{ 14031 } [ 

ISO  A3  Landscape  (420mro  x 297nun) 
{#horizontal { 13200} ,#vertical { 20400 } | 

ANSI  B Portrait  (llin  x 17in) 
{#horizontal{ 20400} ,#vertical{ 13200} 

ASNI  B Landscape  (17in  x llin) 

") 

DEFINE ( NON -BASIC- NON- PAG - S I Z , " 

{#horizontal{ 14031 } ,#vertical{ 19843} [ 

ISO  A3  Portrait  (297mm  x 420inm) 
{#horizontal { 19843 } ,#vertical{ 14031 } j 
ISO  A3  Landscape  (420mm  x 297mm) 
{#horizontal{ 13200} ,#vertical{ 20400} j 
--  ANSI  B Portrait  (llin  x 17in) 
{#horizontal{ 20400} ,#vertical{ 13200} 

ASNI  B Landscape  (17in  x llin) 

") 

DEFINE ( BAS I C - CHAR - ORI ENTATION , " 

{ '0-degrees ' } 

.,) 

DEFINE (NON- BAS I C - CHAR- ORI ENTATION , " 

{ ' 90-degrees ' ) 

DEFINE(BASIC-CHAR-PATH, " 

{'0-degrees'  | '90-degrees' 

") 

DEFINE(NON-BASIC-CHAR-PATH, " 

{'180-degrees'  | '270-degrees'} 

") 

DEFINE (FDA, "formatted  (0)") 
DEFINE(PDA,"processable  (1)") 
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DEFINE(FPDA, " formatted-processable  (2)") 

DEFINE (DAC," 

Docuiiient-profile{#Document- character  is  tics 
{#Document-architecture-class } ) " ) 

DEFINE (CF,  "{2  8 2 6 0}")--  Character  formatted 
DEFINE(CP, " { 2 8 2 6 1)")--  Character  processable 
DEFINE (CFP ."{ 2 8 2 6 2)")--  Character  formatted  processable 
DEFINE (RFP 2 8 2 7 2)")"“  Raster  formatted  processable 
DEFINE(GFP, " {2  8 2 8 0)")--  Graphics  formatted  processable 

DEFINE (FACTOR, "factor-set  (2)") 

DEFINE (COMPLETE , "complete -generator- set  (1 ) " ) 

DEFINE (PRESENT, "present  (1)") 

17.7.1.2Gonstituent  constraints 

17.7.1,2. IPresence  of  document  constituents 
CASE  {$DAG  OF 

$FDA: 

PERM  Generic- layout-structure { $FACT0R} ; 

REQ  Specif ic- layout-structure { $PRESENT} ; 

PEPdi  Presentation- sty ies{$PRESENT}  ; 

$PDA: 

PERM  Generic- layout-structure { $C0M.PLETE}  ; 

REQ  Generic-logical-structure { $C0MPLETE} ; 

REQ  Specific-logical-structure{$PRESENT) ; 

PERM  Presentation- s ty les { $PRESENT} ; 

PERM  Layout- styles { $PRESENT ) ; 

$FPDA: 

REQ  Generic-layout-structure{$COMPLETE) ; 

REQ  Specific-layout-structure{$PRESENT) ; 

REQ  Generic-logical-structure  {$C0MPLETE}; 

REQ  Specif ic- logical-structure { $PRESENT} ; 

PERM  Presentation-styles { $PRESENT) ; 

PERM  Layout-styles  {$PRESENT); 

) 

PERM  External - document -c las s {ANY_VALUE} ; 

PERM  Resource-document {AMY_VALUE) ; 

PERM  Resources  {ANY__VALUE)  ; 

17.7.1.2. 2Document  characteristics 

REQ  Document-application-prof ile { 1 3 14  11  0 1 0}; 
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REQ  Doc-appl-prof ile-defaults { { REQ  #Docuinent-architecture-defaults { 

CASE  {$DAC  OF 

$FDA; 

PERM  #Content”architecture-class { $FC} , 

$PDA: 

REQ  #Content-archi tec ture-c lass {$PC} ^ 

$FPDA: 

REQ  #Content-architecture-class{$FPC} , 

} 

PERM  #Page-dimensions{$BASIC-PAG-DIM  | $NON-BASIC-PAG-DIM  \ 
$NON-BASIC-NOM-PAG-SIZE) , 

PERM  #Mediiuii- type  { 

REQ  #Noininal-page-size{$BASIC-PAG-DIM  | $NON-BASIC-PAG-DIM}  , 

REQ  #Side-of-sheet{ANY_VALUE} } , 

PERM  #Character- contents -defaults { 

PERM  #Character-path{$BASIC-CHAR-PATH  j $NON- BASIC -CHAR- PATH } , 

PERM  #Character-orlentation{ $BASIC-CHAR-ORIENTATION  j 
$NON-BASIC-CHAR-ORIENTATION} , 

PERM  #Character-spacing{ ANY_VALUE} , 

PERM  #Line - spac ing { ANY_VALUE ) , 

PERM  #Graphic-rendition{ANY_EXCEPT  26, 

Variable  spacing 

50)  , 

Not  variable  spacing 
PERM  #Graphic- char- subrepertoire 

{$BASIC- SUBREPERTOIRES  j $NON-BASIC-SUBREPERTOIRES ) , 

PERM  #Widow- s ize { ANY_VALUE } , 

PERM  #Orphan- s ize  { A.NY_VALUE } , 

PERM  #Graphic-character-sets { { $BASIC-CHAR-SET  j 
$NON-BASIC-CHAR-SET}+} , 

PERM  indentation { ANY__VALUE } , 

PERM  #Kerning- offset { ANY_VALUE) , 

PERM  #Proportional- line-spacing 
{ANY_VALUE} , 

PERM  #Pair-wise-kerning{ANY__VALUE}  , 

PERM  #Code- extension- announcers 
{ {$CODE-EXT-ANNOUNCERS}+) ) , 

Note:First-line-offset  not  permitted  here. 

PERM  Raster-gr-contents-defaults  { 

PERM  #Pel-path{ ' 0-degrees ' j '180-degrees'}, 

PERM  #Line-progression{ ' 90-degrees ' | ' 270-degrees , 

PERM  #Pe 1- spac ing {ANY_VALUE  <1200} , 

PERM  #Compression{ANY_VALUE} , 

PERM  #Pel-bit-order{ 'up'  j 'down'}}, 

Note : Inclusion  presumes  approval  by  ISO. 
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PERM  Geo-gr-contents-defaults { ANY_VALUE} 

): 

REQ  Document-architecture-class  {$FDA  j $PDA  | $FPDA) ; 

REQ  Content-architecture-class  {$CF  | $CP  j $CFP  | $RFP  | $GFP} ; 

REQ  Interchange- format-class { if-a  (0)}; 

REQ  ODA- vers ion  { 

REQ  #standard-or-reconunendation{  "ISO  8613"), 

REQ  #publication-date{ "1989-07-04" ) ); 

REQ  Non-basic-doc-characteristics  { { 

REQ  #Prof ile-character-sets  {{ $BASIC- CHAR- SET  | 

$NON-BASIC-CHAR-SET)+} , 

"Profile-character-sets"  designate  and  invoke  character  sets  used  in 
attributes  to  which  "Profile-character-sets"  is  applied, 

REQ  #Comment-character- sets {{ $BASIC-GHAR- SET  j 

$N0N-BAS IC- CHAR- SET }+} , 

"Comment-character-sets"  specifies  the  initial  designated  graphic 
character  sets  and  shift  status  of  "User-readable-comments"  and 
"User-visible-name".  Designation  to  the  same  G set  overrides  the 
previous  designated  graphic  character  set  in  "Comment-character-sets". 

All  the  graphic  character  sets  used  in  "User-readable-comments"  and 
"User-visible-name"  should  be  designated  and/or  Invoked  in 
"Comment-character-sets". 

REQ  #Alternative- representation- character -sets 

{ {$BASIC-CHAR-SET  | $NON-BASIC-CHAR-SET} , 
"Alternate-representation-character-sets"  designate  and  invoke 
character  sets  used  in  attributes  to  which 
"Alternate-representation-character-sets"  is  applied, 

REQ  #Page-dimensions{$BASIC-PAG-DIM  | $NON-BASIC-PAG-DIM) , 

REQ  #Medium- types { 

REQ#Nominal -page  - s ize 
{$NON-BASIC-NOM-PAG-SIZ} , 

REQ#Side-of-sheet{ ANY_VALUE) , 

PERM  #Char-presentation-features { 

PERM#Character-path{ {$NON-BASIC-CHAR-PATH}+  ) ; 

PERM#Charac ter- orientation 
{$NON-BASIC-CHAR-ORIENTATION) ; 

PERM#Character-spacing{ANY_INTEGER  <100) , 

PERM#Line- spacing {100  | 150  | ANY_INTEGER  > 200), 

PERM#Graphic- char- subrepertoire 
{ ($NON-BASIC-SUBREPERTOIRES)+) , 

PERM#Graphic- character- sets 
( {$BASIC-CHAR-SET  | $NON-BASIC-CHAR-SET)+) , 

PERM  #Ra-gr-presentation-features ( 

PERM#Pel-path{ ' 180-degrees ' ) , 

PERM#Line-progression{ '90-degrees' ) , 

PERM#Compression{ 'uncompressed' ) ) 

); 
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PERM  Additional-doc-characterlstics { 

REQ  #Fonts-list{ANY_VALUE} , 

PERM  #Unit-scaling{ANY_VALUE}  ); 

17 . 7 . 1 . 2 . 3Document  management  attributes 

PERM  Document-description! ANY_VALUE) ; 

PERM  Dates-and- times {ANY_VALUE} ; 

PERM  Originators {ANY_VALUE } : 

PERM  0 ther- user- information! ANY_VALUE} ; 

PERM  External-references !ANY_VALUE} ; 

PERM  Locai-file-references!ANY_VALUE) ; 

PERM  Content-attributes !ANY_VALUE} ; 

PERM  Security- information!ANY_VALUE} ; 

17.7.2  Logical  constituent  constraints 

Note:  The  production  rules  for  the  Generator-for-subordinates  for  the 
logical  constraint  objects  has  not  as  yet  been  aligned  with  the 
notation  used  in  the  PAGODA  DAPs. 

17 . 7 . 2 . IDiagrams  of  relationships  of  logical  constituents 

The  notation  used  for  the  structure  diagrams  is  that  specified  in 
Appendix  A of  ISO  8613-2. 

The  following  diagrams  represent  the  primary  graph  for  the  complete 
generator  set  of  logical  object  class  descriptions. 
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Figure  17.4:  Structure  for  LogDoc  and  Passage 


17-14 


Figure  17.5:  Structure  for  Paragraph 


Figure  17.6:  Structure  for  FNote 
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Figure  17.7:  Structure  for  NumberedSegment 


The  following  diagram  corresponds  to  the  logical  object  class 
descriptions  referenced  by  the  attribute  "Logical  Source"  in  layout 
components . 


Figure  17.8:  Structure  for  CommonContent 
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17 . 7 . 2 . 2Macro  definitions 


DEFINE (N, " 

<n>  : :=--any  character  string  from  the  set  of  characters: 

II Q II  II  II  II  g II II  ^ 

DEFINE ( NUMBERS, " 

<numbers>: :="number-"+<$N>  ") 

This  binding  can  be  instanced  for  use  as  the  numeric  values  for  use 
in  a segment  number  or  footnote  number  bindings.  The  instances  are 
differentiated  by  the  suffix  ntjmber. 

DEFINE (NUMBERSTRINGS , " 

<numberstrings>:  :="numberstring- ''+<$N>  ") 

This  binding  can  be  instanced  for  use  as  the  string  value  for  the 
segment  number  or  footnote  number  text.  The  instances  are 
differentiated  by  the  suffix  number. 

DEFINE (PREFIXES,” 

<pref ixes>:  :="pref ix- ”-f<$N>  ") 

DEFINE ( SUFFIXES, " 

<suff ixes>:  :=”suffix- "-f<$N>  ") 

DEFINE (SEPARATORS , " 

<separators>: separator- "+<$N>  ") 

DEFINE ( STRINGFUNCTION , " 

<string-functlon>:  :=MK_STR  | U_ALPHA  j L_ALPHA  | U__ROM  I L_ROM  | ' 'H  ") 

DEFINE (INITIALISEANY, " 

<binding-pair-constraint>  : := 

<$PREFIXES>,  STRING_LITERAL  j 
<$SUFFIXES>,  STRING_LITERAL  I 
<$SEPARATORS>,  STRING_LITERAL  | 

<$NUMBERS>,  NUMERIC_LITERAL  | 

<$NUMBERSTRINGS>,  " " | 

"PGnum",  NUMERIC_LITERAL 
Used  to  initialize  any  of  the  bindings. 

") 

DEFINE (USENUMBERSTRING, " 

<binding-pair-constraint>: := 

<$NUMBERSTRINGS>,  <hierarchic-expr>  | <simple-expr> 

<hierarchic-expr>: := 

B_REF(SUP(CURR_OBJ))  (<$NUMBERSTRINGS>)  +B_REF(SUP(CURR_OBJ) ) 
(<$SEPARATORS>)+<simple-expr) " ) 

<simple-expr>: := 
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<$STRINGFUNCTION>  (B_REF(CURR_OBJ) ($NIMBERS) ) | 

<$STRINGFUNCTION>  (ORD(CURR_OBJ) ) | STRING -LITERAL 

Used  to  make  a simple  or  compound  string  out  of  the  number 
bindings. 

") 

DEFINE (USENUMBERS , " 

<binding-pair-constraint>: := 

<$fJUM.BERS> , INC  ( B_REF  ( PREC  ( CURR_03J  ) ) (<$KUMBERS>) 

Used  to  increment  any  of  the  number  bindings. 

") 

DEFINE (SEGMENTNUMBER, " 

<string-expr-constraint>: := 

[ <s gpre - s t r> ] -Ks gnum- s t r>+ [ <s gsuf - s tr> ] 

<sgnum-str>: :=B_REF(SUP(CURR_OBJ) ) (<$NUMBERSTRINGS>) 

<sgpre-str>: ;=B_REF(SUP(CURR_OBJ))  (<$PREFIXES>)  j STRING_LITERAL 
<sgsuf-str>: :=B_REF(SUP(CURR_OBJ))  (<$SUFFIXES>)  | STRING_LITERAL 

This  expression  is  allowed  in  content  generators  for  the  Number 
constraint  object  to  automatically  generate  text  for  segment  numbers. 

") 

DEFINE  (PGNUMBER/' 

<string-expr-constraint>: := 

[ <pgpre - s t r> ] -Kpgnum- s tr>+ [ <pgsuf - s t r> ] 

<pgpre-str>: : =STRING_LITERAL 
<pgsuf-str>: :=STRING_LITERAL 

<pgnum-str>: :=<$STRINGFUNCTION>  (<numeric-expr>) 

<numeric-expr>: := 

B_REF(SUP(CURR_INST(  <class-or- typel>,  CURR_OBJ)))  ("PGnum")  j 
B_REF(CURR_INST(<class-or-type2>,  CURR_OBJ))  ("PGnum") 
<class-or-type-l>: :=FRAME 

<class-or-type-2>: ;=PAGE  ! OBJ ECT_CLASS_ID_OF( Page  j RPage  | VPage) 

This  expression  is  alloed  in  content  generators  for  the  PageNumber 
constraint  object  to  automatically  generate  text  for  page  numbers. 

") 

DEFINE ( FNNUMBER, " 

<string-expr-constraint>: := 

[ <f npre - s t r> ] +<f nnum - s t r>+ [ <f nsuf - s t r> ] 

<fnnum-str>: :=B_REF(SUP(CURR_OBJ))  (<$NUMBERSTRINGS>)  | STRING_LITERAL 
<fnpre-str>: :=B_REF(SUP(CURR_OBJ))  (<$SUFFIXES>)  | STRING_LITERAL 
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This  expression  is  allowed  in  content  generators  for  the  Number 
constraint  object  to  automatically  generate  text  for  footnote  numbers. 

") 

DEFINE ( LOGDOCGFS, ” 

<constr-expr>:  :=OPT(REP(OBJECT_GLASS__ID(Passage)  ) ) ") 

DEFINE ( PASS AGEGFS , " 

<cons  t r ~ expr> : : =REP ( GHO ( OPT ( REP ( CHO ( OBJ  ECT_CLAS  S_ID ( BodyTex t ) \ 
OBJECT_CLASS_ID(BodyRaster)  | OBJECT_CLASS_ID(BodyGeometric)  | 
0BJECT_C1ASS_ID (Paragraph))))  1 
OPT(REP(OBJEGT_CLASS_ID(NumberedSegment) ) ) ) ") 

DEFINE (NUMBEREDSEGMENTGFS , ” 

<constr-expr>: :=SEQ(OBJECT_CLASS_ID(Number) , 

OPT(REP(CHO(OBJECT_CLASS_ID(BodyText)  j OBJECT_CLASS_ID(BodyRaster)  | 
OBJECT_CLASS_ID(BodyGeometric)  j OBJECT_CLASS_ID ( Paragraph) ))) , 
OPT(REP(OBJECT_CLASS_ID(NumberedSegment) ) ) ) " ) 

DEFINE (PARAGRAPHGFS , " 

<constr-expr>: :=OPT(REP(CHO(OBJECT_CLASS_ID(BodyText)  | 
OBJECT_CLASS_ID(BodyRaster)  ! OBJECT_CLASS_ID(BodyGeometric)  | 
OBJECT_CLASS_ID(FNote))))  ") 

DEFINE ( FNOTEGFS, " 

<constr-expr>:  :=SEQ(OBJECT_CLA,SS_ID(Number)  , OBJECT_CLASS_ID(FNBody)  ) ") 

DEFINE (FNBODYGFS , " 

<constr-expr>: ;=SEQ(OBJECT_CLASS  ID (Number) , OBJECT_ClASS_ID(BodyText) ) 

") 

DEFINE (COMMONCONTENTGFS , " 

<constr-expr>;  :=REP(CHO(OBJECT_CLASS_ID(ConimonText)  | 
OBJECT_CLASS_ID(CommonRaster)  j OBJECT_ClASS_ID(CoinmonGeometric)  j 
OBJECT_CLASS_ID(PageNumber)))  ") 
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17.7.2.3Factor  constraints 


FACTOR : ANY- LOGICAL { 

GENERIC: 

REQ  Ob j ect- type {VIRTUAL} ; 

REQ  Object-class-identifier{ANY_VALUE} ; 

PERM  Re  s our c e ( ANY_VALUE ) ; 

SPECIFIC: 

PERM  Obj ect- type { VIRTUAL ) ; 

REQ  Obj ect- identifier ( ANY_VALUE } ; 

REQ  Obj ect-class (VIRTUAL) ; 

SPECIFIC_AND_GENERIC : 

PERM  Layout-style (VIRTUAL) ; 

PERM  Protection{ANY_VALUE} ; 

PERM  User- readable- comment {ANY_VALUE) ; 

PERM  User-visible-name {ANY_VALUE) ; 

) 

FACTOR : COMP - LOG I CAL : ANY - LOG I CAL { 

GENERIC : 

REQ  Obj ect- type {COMPOSITE_LOGICAL_OBJECT} ; 

SPECIFIC: 

REQ  Subordinates (VIRTUAL) ; 

PERM  Obj ect- type {COMPOSITE_LOGICAL_OBJECT) ; 

SPECIFIC_AND_GENERIC : 

PERM  Layout-style {STYLE_ID_0F(LStyle3) ) ; 

PERM  De f ault- value -1 is ts{ANY_VALUE} ; 

) 

FACTOR : BAS I C - LOG I CAL : ANY - LOG I CAL { 

GENERIC : 

REQ  Obj ect- type {BASIC_LOGICAL_OBJECT} ; 

SPECIFIC: 

PERM  Object-type{BASIC_LOGICAL_OBJECT} ; 

PERM  Content -portions { ANY_VALUE ) ; 

} 

FACTOR : ANY- COMMON { 

GENERIC : 

REQ  Obj ect- type (VIRTUAL) ; 

REQ  Object-class-identifier{ANY_VALUE) ; 

PERM  Resource {ANY_VALUE } ; 
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PERM  Bindings {VIRTUAL} : 

PERM  Protection(ANY_VALUE) ; 

PERM  User-readable-comments {ANY_VALUE} ; 

PERM  User-visible-name (ANY] ; 

} 

17 . 7 . 2 .4Constituent  constraints 
17 . 7 . 2 .4 . ILogDoc : ANY-LOGICAL{ 

GENERIC; 

REQ  Ob j e c t - typ  e { DOCUMENT_LOG I C AL_ROOT } ; 

REQ  Generator- for-subordinates{$LOGDOCGFS} ; 

SPECIFIC: 

REQ  Object-class(OBJECT_CLASS_ID_OF(Logdoc) } ; 

REQ  Subordinates {( SUBORDINATE_ID_OF(  Passage)+) } ; 

PERM  Obj  ect- type ( DOCUMENT_LOGICAL_ROOT } 

SPECIFIC_AND_GENERIC : 

PERM  Layout-style(STYLE_ID_OF(LStylel) } ; 

PERM  Bindings { $INITIALISEANY) ; 

PERM  Default-value- lists (ANY_VALUE) ; 

PERM  Application-comments { "LogDoc" } ; 

) 

17.7.2.4. 2Passage : COMP-LOGICAL{ 

GENERIC: 

REQ  Generator- for- subordinates ($PASSAGEGFS} ; 

SPECIFIC: 

REQ  Obj ect- class {OBJECT_CLASS_ID_OF( Pas sage) ) ; 

REQ  Subordinates (([ SUBORDINATE_ID_OF(  Paragraph)  ( 

SUBORDINATE_ID_OF(BodyText)  [ SUBORDINATE_ID_OF(  BodyRaster)  | 
SUBORDINATE_ID_OF(  BodyGeometric) }+]  | [ ( SUBORDINATE_ID_OF( 
NumberedSegment) )+) ; 

SPECIFIC_AND_GENERIC : 

PERM  Bindings ($INITIALISEANY  | $USENUMBERS } ; 

PERM  Appl icat ion- comments { "Passage" ) ; 

) 

17.7. 2 .4.  SNusnberedSeginent : COMP-LOGICAL{ 

GENERIC: 

REQ  Generator  - for -- subordina  tes  { $NUMBEREDSEGMENTGFS } ; 

REQ  Bindings { $USENUMBERS ) ; 

REQ  Application-comments] "NumberedSegment" ) ; 
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SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  NumberedSegment) } ; 

REQ  Subordinates {SUBORDINATE_ID_OF (Number) , 

{ [SUBORDINATE_ID_OF(BodyText)  [ SUBORDINATE_ID_OF(  BodyRaster)  | 
SUBORDINATE_ID_OF(  BodyGeometric)  | SUBORDINATE_ID_OF(  Paragraph) ] }+, 

[ {SUBORDINATE_ID_OF(  NumberedSegment) )+] ) ; 

PERM  Bindings {$INITIALISEANY  | $USENUMBERS ) ; 

PERM  Application-comments { "NumberedSegment" } ; 

} 

17.7.2.4.4Number:BASIC-L0GICAL{ 

GENERIC: 

REQ  Content- generator {$SEGMENTNUMBER  | $FNNUMBER} ; 

REQ  Application-comments { "Number" ) ; 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(Number) ) ; 

PERM  Application-comments { "Number" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Presentation-style{ STYLE_ID_OF(PStylel) } ; 

PERM  Layout-style {STYLE_ID_0F(LStyle4) } ; 

PERM  Content-architecture-class { $CF  | $CP  | $CFP) ; 

) 

17.7. 2 .4. SParagraph: COMP -LOGICAL! 

GENERIC: 

REQ  Generator- for- subordinates { $PARAGRAPHGFS ) ; 

REQ  Application-comments { "Paragraph" } ; 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  Paragraph)); 

REQ  Subordinates! [ {SUBORDINATE_ID_OF(BodyText)  | SUBORDINATE_ID_OF( 

BodyRaster)  j SUBORDINATE_ID_OF(  BodyGeometric) )+]) ; 

PERM  Application-comments ! "Paragraph" } ; 

) 

17.7.2.4. 6FNote : COMP-LOGICAL! 

GENERIC: 

REQ  Generator- for- subordinates ! $FNOTEGFS } ; 

REQ  Application-comments! "FNote" ) ; 

SPECIFIC: 

REQ  Object-class !OBJECT_CLASS_ID_OF(FNote) } ; 

REQ  Subordinates ! SUBORDINATE_ID_OF(Number) , 

SUBORDINATE_ID_OF(FNBody) } ; 

PERM  Application-comments ! "FNote" ) ; 
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SPECIFIC_AND_GENERIC : 

PERM  Bindings {$INITIALISEANY  | $USENUMBERS ) ; 

) 

17.7. 2 .4. 7FNBody : COMP-LOGICAL{ 

GENERIC: 

REQ  Generator- for-subordinates{$FNBODYGFS} ; 

REQ  Application-conunents  { "FNBody”  ) ; 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(FNBody) } ; 

REQ  Subordinates { SUBORDINATE_ID_OF(Number) , 

SUBORDINATE_ID_OF(BodyText) ) ; 

PERM  Application-conunents  { "FNBody"  ) ; 

) 

17.7.2.4. SBodyText: BASIC -LOGICAL! 

GENERIC: 

REQ  Application-conunents  { "BodyText"  ) ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF(  BodyText)}; 

PERM  Application-conunents  { "BodyText"  ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Content-architecture-class { $CF  j $CP  | $CFP} ; 
PERM  Content-portions {ANY_VALUE} ; 

PERM  Presentation-style! STYLE_ID_0F(PStyle2) } ; 

PERM  Layout-style !STYLE_ID_0F(LStyle5) ) ; 

) 

17.7.2.4. 9BodyRaster: BASIC -LOGICAL! 

GENERIC: 

REQ  Application-conunents ! "BodyRaster"  ) ; 

SPECIFIC: 

REQ  Obj ect-class !OBJECT_CLASS_ID_OF(  BodyRaster)}; 

PERM  Application-conunents  ! "BodyRaster"  } ; 

SPECIFIC_AND_GENERIC : 

PERM  Content-architecture-class ! $RFP} ; 

PERM  Content-portions !ANY_VALUE} ; 

PERM  Presentation-style! STYLE_ID_0F(PStyle3) } ; 

PERM  Layout-style ! STYLE_ID_OF(LS tyle6) } ; 

} 

17.7.2.4. lOBodyGeome tr ic : BAS I C - LOGICAL ! 
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GENERIC: 

REQ  Application-comments { "BodyGeometric" ) ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF(  BodyGeometric)}; 

PERM  Application-comments { "BodyGeometric" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Content-architecture-class { $GFP} ; 

PERM  Content-portions {ANY_VALUE} ; 

PERM  Presentation-style { STYLE_ID_0F(PStyle4) } ; 

PERM  Layout-style {STYLE_ID_0F(LStyle6) } ; 

) 

17.7.2.4. 1 ICoomionContent : ANY-  COMMON  { 

GENERIC: 

REQ  Object- type {COMPOSITE_LOGICAL_OBJECT} ; 

REQ  Generator- for- subordinates { COMMONCONTENTGFS } ; 

REQ  Application-comments { "CommonContent" } ; 

PERM  Default-value-list{ANY_VALUE) ; 

} 

17.7.2.4.1 2PageNuifflber : ANY - COMMON { 

GENERIC: 

REQ  Object- type {BASIC_LOGICAL_OBJECT) ; 

REQ  Content-generator { $PGNUMBER) ; 

PERM  Presentation-style { STYLE_ID_0F(PStyle2) ) ; 

PERM  Content-architecture-class { $CP ) ; 

PERM  Layout-style{STYLE_ID_OF(LStyle2) ) ; 

PERM  Application-comments { "PageNumber" ) ; 

} 

17.7.3  Layout  constituent  constraints 

Note:  The  production  rules  for  the  Generator- for- subordinates  for  the 
layout  constraint  objects  has  not  as  yet  been  aligned  with  the 
notation  used  in  the  PAGODA  DAPs. 


17 . 7 . 3 . IDiagrcuns  of  relationships  of  layout  constituents 

The  notation  used  for  the  structure  diagrams  is  that  specified  in 
Appendix  A of  ISO  8613-2. 
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Figure  17.9:  Structure  for  LayDoc  and  PageSet 
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Figure  17.10:  Structure  for  Page,  VPage  and  RPage 
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Figure  7.11:  Structure  for  CompositeHeaderFooter 


Figure  17.12:  Structure  for  CompositeBody 


17 . 7 . 3 . 2Macro  definitions 
DEFINE (USEPGNUMBER, " 

"PGnum",  INC(B_REF(PREC(CURR_OBJ))  ("PGnum")  ") 
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DEFINE ( LAYDOCGFS, " 

<constr-expr>: :=REP(CHO(OBJECT_CIASS_ID(PageSet) ) ) 

") 

DEFINE ( PAGS ETGFS, " 

<constr-expr>: :=SEQ(OPT(OBJECT_CLASS_ID(Page) ) , 

REP(CHO(REP(OBJECT_CLASS_ID(Page) ) , SEQ(OPT(OBJECT_CLASS_ID(RPage) ) , 
OPT(REP(SEQ(OBJECT_CLASS_ID(VPage) , OBJECT_ClASS_ID(RPage) ) ) ) , 
OPT(OBJECT_CLASS_ID(VPAGE) ) ) ) ) ) 

DEFINE ( PAGEGFS, ” 

<constr-expr>: :=AGG(CHO(OPT(OBJECT_CLASS_ID(  BasicHeaderFooter) ) , 
OPT(OBJECT_CLASS_ID(  CompositeHeaderFooter) ) ) , 

CHO(OBJECT_CLASS_ID(BasicBody) , OBJECT_CLASS_ID(CompositeBodyFixed) ) , 
CHO(OPT(OBJECT_CLASS_ID(  CompositeHeaderFooter)) , OPT(OBJECT_CLASS_ID( 
BasicHeaderFooter) ) ) ) 

") 

DEFINE ( COMPOS ITEHFGFS , " 

<constr-expr>: :=CHO(REP(CHO(  OBJECT_CLASS_ID(SourcedContentVariable) , 
OBJECT_CLASS_ID(ArrangedContentVariable))) , REP(CHO( 

OBJECT_CLASS_ID ( SourcedContentFixed) , 
OBJECT_CLASS_ID(ArrangedContentFixed) ) ) ) 

") 

DEFINE ( COMPOS ITEBODYFIXEDGFS , " 

<constr-expr>: ;=REP(CHO(OBJECT_CLASS_ID(ColumnVariable) , 
OBJECT_CLASS_ID(ColumnsSynchronized) , OBJECT_CLASS_ID(ColumnsSnaking) , 
OBJECT_CLASS_ID(Footnote) ) ) 

") 

DEFINE (ARRANGEDCONTENTFIXEDGFS , " 

<constr-expr>: :=REP(OBJECT_CLASS_ID( Block) ) 

") 

DEFINE (ARRANGEDCONTENTVARIABLEGFS , " 

<constr-expr>: :=REP( OBJ ECT_CLASS_ID( Block) ) 

") 

DEFINE (COLUMNSSNAKINGGFS , " 

<constr-expr>: :=REP(OBJECT_CLASS_ID(ColumnVariable) ) 

") 

DEFINE ( COLUMNS SYNCHRONIZEDGFS , " 

<cons  tr - expr> : : =SEQ ( OBJECT_CLASS_ID ( Co lumnFixed) 

") 

17.7.3.3Factor  constraints 
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FACTOR : ANY- LAYOUT { 


GENERIC: 

REQ  Obj ect- type { VIRTUAL) ; 

REQ  Object-class-identifier{ANY_VALUE} ; 

SPECIFIC: 

PERM  Obj ect- type { VIRTUAL } ; 

REQ  Obj ect- identifier {ANY_VALUE} ; 

REQ  Obj ect-c lass (VIRTUAL) ; 

P-EQ  Subordinates  (VIRTUAL) ; 

SPECIFIC_AND_GENERIC : 

PERM  User -visible -name ( ANY_VALUE ) ; 

PERM  User-readable-comment (ANY_VALUE) ; 

) 

FACTOR : ANY- PAGE : ANY- LAYOUT ( 

GENERIC: 

REQ  Obj ect- type ( PAGE ) ; 

CASE  ($DAC  OF 

$FDA: 

PERM  Generator- for- subordinates ( $PAGEGFS ) ; 

$PDA: 

REQ  Generator- for- subordinates ( $PAGEGFS ) ; 

$FPDA: 

REQ  Generator-for-subordinates ( $PAGEGFS ) ; 

PERM  Bindings ( [$INITIALISEANY] , $USEPGNUMBER) ; 

PERM  Resource ( ANY_VALUE ) ; 

SPECIFIC: 

REQ  Subordinates ([ SUBORDINATE_ID_OF(  BasicHeaderFooter  | 

CompositeHeaderFooter) ] , SUBORDINATE_ID_OF(BasicBody  | 
CompositeBodyFixed) , [ SUBORDINATE_ID_OF(  CompositeHeaderFooter  j 
BasicHeaderFooter)]  ); 

PERM  Obj ect- type ( PAGE) : 

SPECIFIC_AND_GENERIC : 

PERM  Dimensions (ANY- VALUE ) ; 

PERM  Transparency ( ANY_VALUE ) : 

PERM  Colour(ANY_VALUE) : 

PERM  Page-position(ANY_VALUE) ; 

PERM  Bindings ( $USEPGNUMBER) ; 

) 

FACTOR : ANY - FRAME : ANY - LAYOUT ( 

GENERIC: 

REQ  Obj ect- type ( FRAME ) ; 
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SPECIFIC: 

PERM  Obj ect- type { FRAME } ; 

REQ  Subordinates {VIRTUAL} ; 

PERM  Layout - path ( VIRTUAL } ; 

) 

17 . 7 . 3 .4Constituent  constraints 
17.7.3.4. ILayDoc : ANY-LAYOUT{ 

GENERIC: 

REQ  Ob j ec  t - type { DOCUMENT_LAYOUT_ROOT ) ; 

REQ  Generator- for- subordinates { $LAYDOCGFS } ; 

PERM  Resource (ANY_VALUE ) ; 

SPECIFIC: 

CASE  ($DAC  OF 

$FDA: 

PERM  Obj ect-class (OBJECT_CLASS_ID(LayDoc) ) ; 

$PDA: 

REQ  Ob j ect- class} OBJ ECT_CLASS_ID_OF(LayDoc) } ; 

$FPDA: 

REQ  Obj ect-class ( OBJ ECT_CLASS_ID_OF(LayDoc) } ; 

REQ  Subordinates ( SUBORDINATE_ID_OF(  PageSet)+} ; 

PERM  Obj  ect - type ( DOCUMENT_LAYOUT_ROOT } ; 

SPECIFIC_AND_GENERIC : 

PERM  Default-value-lists(ANY_VALUE) ; 

PERM  Bindings { $INITIALISEANY) ) ; 

PERM  Application-comments { "LayDoc" ) ; 

) 

17.7.3.4. 2PageSet : ANY- LAYOUT ( 

GENERIC: 

REQ  Obj ect- type { PAGE_SET } ; 

REQ  Generator- for- subordinates { $PAGESETGFS ) ; 

PERM  Resource {ANY_VALUE } ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF(PageSet) } ; 

REQ  Subordinates}  } [SUBORDINATE_ID_OF(Page) ]+, 

[ SUBORDINATE_ID_OF(RPage) ] , [ SUBORDINATE_ID_OF(VPage) , 
SUBORDINATE_ID_OF(RPage) ]+,  [ SUBORDINATE_ID_OF(VPage) ] } } ; 
PERM  Obj ect- type } PAGE_SET ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Bindings } $INITIALISEANY} ; 

PERM  Application-comments } "PageSet" } ; 
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) 

17.7.3.4.3Page:ANY-PAGE{ 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(Page) ) ; 

SPECIFIC_AND_GENERIC : 

REQ  Medium- type { NON_BAS IC ) ; 

PERM  Application-comments { "Page" } ; 

} 

17 . 7 . 3 . 4 . 4RPage : ANY- PAGE { 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(RPage) } ; 

SPECIFIC_AND_GENERIC : 

REQ  Medium- type { NON_BASIC ) : 

PERM  Application-comments { "RPage" } ; 

} 


17 . 7 . 3 . 4 . SVPage : ANY- PAGE { 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(VPage) ) ; 

SPECIFIC_AND_GENERIC : 

REQ  Medium- type { NON_BASIC } : 

PERM  Application-comments { "VPage" } ; 

} 

17.7.3.4. SCompositeHeaderFooter : ANY- FRAME { 

GENERIC: 

REQ  Generator- for- subordinates { $COMPOSITEHFGFS } ; 

REQ  Position{#f ixed{ ANY_VALUE) } ; 

REQ  Dimensions{#horizontal{  #f ixed{ ANY_VALUE } ) , 

#vertical{#fixed{ANY_VALUE} ) } ; 

REQ  Application-comments! "CompositeHeaderFooter" } ; 

PERM  Resource { ANY_VALUE } : 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  CompositeHeaderFooter)}; 

REQ  Subordinates {{ SUBORDINATE_ID_OF(  SourcedContentVariable)  | 

SUBORDINATE_ID_OF(  ArrangedContentVarlable) }+  | { SUBORDINATE_ID_OF( 
SourcedContentFixed)  | SUBORDINATE_ID_OF(  ArrangedContentFixed) }+  } ) 
PERM  Imaging- order { ANY_VALUE ) : 

PERM  Application-comments { "CompositeHeaderFooter" } ; 
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SPECIFIC_AND_GENERIC : 

PERM  Transparency { ANY_VALUE ) ; 

PERM  Colour { ANY_VALUE } ; 

PERM  Border  { AirY_VALUE } ; 

PERM  Layout-path { ANY_VALUE ) ; 

) 

17.7. 3 .4. 7CompositeBodyFixed: ANY-FRAME{ 

GENERIC : 

REQ  Generator- for- subordinates {$COMPOSITEBODYFIXEDGFS) ; 

REQ  Position{#f ixed{ ANY_VALUE) } ; 

REQ  Dimensions {#horizontal { #f ixed( ANY_VALUE} ) , 

#vertical {#f ixed{ ANY_VALUE) ) ) ; 

REQ  Application-comments { "CompositeBodyFixed" ) ; 

PERM  Resource { ANY_VALUE ) ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF  (CompositeBodyFixed)}; 

REQ  Subordinates! {SUBORDINATE_ID_OF(  ColumnVariable)  | 
SUBORDINATE_ID_OF(  SynchronizedColumns)  | SUBORDINATE_ID_OF( 
SnakingColumns)  | SUBORDINATE_ID_OF(FootNote) )+  }; 

PERM  Position{ANY_VALUE} ; 

PERM  Dimensions {#horizontal { #f ixed{ANY_VALUE} ) , 

#vertical{#fixed{ANY_VALUE} ) } ; 

PERM  Imaging-order {ANY_VALUE) ; 

PERM  Application-comments { "CompositeBodyFixed" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Transparency {ANY_VALUE} ; 

PERM  Colour { ANY_VALUE ) ; 

PERM  Border { ANY_VALUE } ; 

} 

1 7 . 7 . 3 . 4 . 8Co lumnFixed : ANY- FRAME { 

GENERIC: 

REQ  Position{#fixed{ANY_VALUE} ) ; 

REQ  Dimensions{#horizontal{#fixed{ANY_VALUE)  | #maximum-size ) , 

#vertical{#rule-b{ANY_VALUE}  j #maximum-size } } ; 

REQ  Application-comments { "ColumnFixed" ) ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF(  ColumnFixed)}; 

REQ  Subordinates! !OBJECT_ID_OF(Block) }+} ; 

PERM  Position!ANY_VALUE} ; 

PERM  Dimensions !#horizontal!  #f ixed! ANY_VALUE } } , 

#vertical !#f ixed! ANY_VALUE} } } ; 

PERM  Imaging- order ! ANY_VALUE } ; 
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PERM  Application-comments { "ColumnFixed" } ; 


SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories {ANY_VALUE) ; 

PERM  Transparency { ANY_VALUE ) ; 

PERM  Co lour { ANY_VALUE } ; 

PERM  Border { ANY_VALUE ) ; 

) 

17 . 7 . 3 . 4 . 9Coluim¥ariable : ANY- FRAME  { 

GENERIC : 

REQ  Position{#variable{ANY_VALUE) ) ; 

REQ  Dimensions {#horlzontal {#fixed{ANY_VALUE)  | #maximum-size ) , 
#vertical{#rule-b{ANY_VALUE}  j #maximum-size ) } ; 

REQ  Application-comments { "ColumnVariable" } ; 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  ColumnVariable)}; 

REQ  Subordinates} {OBJECT_ID_OF(Block) ]+) ; 

PERM  Position{ANY_VALUE) ; 

PERM  Dimensions  { #horizontal  { #f  ixed{  ANrY_VALUE}  } , 

#vertical{#fixed{ANY_VALUE} } ) ; 

PERM  Imaging- order { ANY_VALUE ) ; 

PERM  Application-comments { "ColumnVariable" ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories {ANY_VALUE} ; 

PERil  Transparency  {ANY_VALUE)  ; 

PERM  Colour { ANY_VALUE } ; 

PERM  Border { ANY_VALUE } ; 

} 

17 . 7 . 3 . 4 . lOSnakingColumns : ANY- FRAME { 

GENERIC: 

REQ  Generator-for-subordinates { $SNAKINGCOLUMNSGFS } ; 

REQ  Posit ion {#variable{ANY_VALUE) } ; 

REQ  Dimens ions {#horizontal{#fixed{ANY_VALUE}  | #maximum-size ) , 

#vertical{#rule-b{ANY_VALUE) } } ; 

REQ  Application-comments { "SnakingColumns" ) ; 

SPECIFIC: 

REQ  Obj ect-class {OBJECT_CLASS_ID_OF(  SnakingColumns)); 

REQ  Subordinates} {SUBORDINATE_ID_OF(  ColumnVariable) }+  ); 

PERM  Position}ANY_VALUE} ; 

PERM  Dimens ions }#hori2ontal}  #fixed}ANY_VALUE} } , 

#vertical}#fixed}ANY_VALUE) } ) ; 

PERM  Imaging- order } ANY_VALUE } ; 

PERM  Application-comments} "SnakingColumns" } ; 
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SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories {ANY_VALUE) ; 

PERM  Transparency { ANY_VALUE ) ; 

PERM  Colour { ANY_VALUE } ; 

PERM  Border { ANY_VALUE } ; 

PERM  Layout-path{ ' 0-degrees ' | '90-degrees’  j '270-degrees'}; 

} 

17.7.3.4.11  SynchronisedColuians ; ANY-  FRAME  { 

GENERIC: 

REQ  Generator- for- subordinates {$SYNCHRONISEDCOLUMNSGFS} ; 

REQ  Position{#variable{ANY_'VALUE) } ; 

REQ  Dimensions {#horizontal{#fixed{ANY_VALUE)  | #maximum-size ) , 

#vertical{#rule-b{ANY_VALUE) } } ; 

REQ  Application-comments { "SynchronisedColumns” ) ; 

SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  SynchronisedColvimns)  } ; 

REQ  Subordinates { {SUBORDINATE_ID_OF(  ColiimnFixed) }+  ); 

PERM  Position{ANY__VALUE} ; 

PERM  Dimens ions {#horizontal{  #f ixed{ ANY_VALUE) ) , 

#vertical{#fixed{ ANY  VALUE) } } ; 

PERM  Imaging-order vaNY_VALUE} ; 

PERM  Application-comments { "SynchronisedColumns" ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories {ANY_VALUE) ; 

Subordinates  of  SynchronisedColumns  must  all  have  different  values 
for  Permitted-categories 
PERM  Transparency { ANY_VALUE } ; 

PERM  Colour { ANY_VALUE } ; 

PERM  Border { ANY_VALUE ) ; 

PERM  Layout-path{ ' 0-degrees ' | '90-degrees’  | '180-degrees'  | 

' 270-degrees ' } ; 

PERM  Balance { ANY_VALUE ) ; 

} 

1 7 . 7 . 3 . 4 . 1 2FootNote : ANY- FRAME { 

GENERIC: 

REQ  Position{#variable{  #offset{ANY_VALUE) , #separation{ANY_VALUE} , 

#alignment {ANY_VALUE} , #fillorder{ 'reversed' ) } ) ; 

REQ  Dimensions {#horizontal {#maximum- size } , #vertical{- 

#rule-b{ANY_VALUE) ) } ; 

REQ  Application-comments { "FootNote" ) ; 

PERM  Resource { ANY_VALUE ) ; 

SPECIFIC: 
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REQ  Object-class {OBJECT__CLASS  ID  OF(  FootNote)  ) ; 

REQ  Subordinates  { { SUBORJDINATE”id“gF( Block) } + ) ; 

PERM  Position{ANY__VALUE}  ; 

PERM  Diinens ions {#horlzontal{#maximum- size) , 
#vertical{#fixed{ANY_VALUE} ) ) ; 

PERM  Imaging- order  { iWY__VALUE } ; 

PERK  Appllcation-comEients{  "FootNote"  } ; 

SPECIFIC_AND__GENERIC : 

REQ  Permitted-categories{ANY_VALUE} ; 

PERM  Transparency { ANY_VALUS } ; 

PERK  Colour { ANY  VALUE ) ; 

PERM  Border { ANY^  VALUE ) ; 

) 

17.7.3.4.1 SArrangedContentFixed : ANY- FRAME { 

GENERIC: 

REQ  Position{#fixed{ANY_VALUE} } ; 

REQ  Dimens ions {#horizontaI{#fixed{ANY_VALUE)  | #rule-b{ANY_VALUE} ) , 

#verticai{#fixed{ANY_VALUE}  | #ruIe-b{ANY_VALUE} ) ) ; 

REQ  Applioation-comments { "ArrangedContentFixed" } ; 

PERM  Generator- for- subordinates {$ARRANGEDCONTENTFIXED) ; 

PERM  Resource { ANY_VALUE } ; 

SPECIFIC: 

REQ  Object-class(OBJECT_CLASS_ID_OF(  ArrangedContentFixed)); 

REQ  Subordinates {SUBORDINATE_ID_OF( Block) }+} ; 

PERM  Position{ANY_VALUE) ; 

PERM  Dimens  ions  {#horizontal{  #f  ixed{Airf_VALUE} } , 

#verticai(#fixed{ANY_VALUE) } } ; 

PERM  Imaging- order { ANY_VALUE ) ; 

PERM  Application-conuaents  1 "A.rrangedContentFixed"  } ; 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories{ANY_VALUE) ; 

PERM  Transparency { ANY_VALUE ) ; 

PERM  Colour { ANY_VALUE ) ; 

PERM  Border { ANY_VALUE } ; 

) 

17.7. 3 .4. 14ArrangedContent¥ariable : ANY-FRAME{ 

GENERIC: 

REQ  Position{#variable{ANY_VALUE} ) ; 

REQ  Dimensioris{#horizontal{#fixed{.ANY_VALUE}  | #rule-b{ANY_VALUE) ) , 

#vertical{#fixed{ANY__VALUE)  | #rule-b{ANY_VALUE} ) ) ; 

REQ  Applicaticn-comments { "ArrangedContentVariable" ) ; 

PERM  Generator- for- su]3ordinates{$ARRANGEDC0NTENTVARIABLE)  ; 

PERM  Resource  { AJIY__VALUE } ; 


17-35 


SPECIFIC: 

REQ  Object-class {OBJECT_CLASS_ID_OF(  ArrangedContentVariable) ) ; 

REQ  Subordinates {SUBORDINATE_ID_OF(Block) }+) ; 

PERM  Position! ANY_VALUE ) ; 

PERM  Dimens ions {#horizontal{  #f ixed{ANY_VALUE) ) , 

#vertical{#fixed{ANY__VALUE) ) ) ; 

PERM  Imaging- order { ANY_VALUE } ; 

PERM  Application-comments! "ArrangedContentVariable" ) ; 
SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories !ANY_VALUE} ; 

PERM  Transparency !ANY_VALUE) ; 

PERM  Colour ! ANY_VALUE } ; 

PERM  Border ! ANY_VALUE ) ; 

) 

17,7.3.4. ISSourcedContentFixed: ANY- FRAME! 

GENERIC: 

REQ  Position!#fixed!ANY_VALUE) ) ; 

REQ  Dimensions !#horizontal ! #f ixed!ANY_VALUE) } , #vertical! 

#rule-b!ANY_VALUE) ) ) ; 

REQ  Logical-source{OBJECT_CLASS_ID_OF(  CommonContent) ) ; 

REQ  Application-comments ! "SourcedContentFixed" ) ; 

PERM  Resource ! ANY_VALUE } ; 

SPECIFIC: 

REQ  Object-class !OBJECT_CLASS_ID_OF(  SourcedContentFixed)}; 

REQ  Subordinates! !SUBORDINATE_ID_OF( Block) }+) ; 

PERM  Position!ANY_VALUE) ; 

PERM  Diraensions!#horizontal!  #f ixed! ANY_VALUE) } , 

#vertical!#fixed!ANY_VALUE) ) ) ; 

PERM  Application-comments ! "SourcedContentFixed" ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Border ! ANY _VALUE } ; 

PERM  Layout - path ! ANY_VALUE ) ; 

} 

17.7.3.4. 16SourcedContentVar iable : ANY- FRAME ! 

GENERIC: 

REQ  Position!#variable!ANY_VALUE} } ; 

REQ  Dlmensions!#horizontal!  #fixed!ANY_VALUE) } , #vertical! 

#rule-b!ANY_VALUE} } ) ; 

REQ  Logical-source!OBJECT_CLASS_ID_OF(  CommonContent)}; 

REQ  Application-comments! "SourcedContentVariable" } ; 

PERM  Resource ! ANY_VALUE } ; 
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SPECIFIC: 

REQ  Object-class{OBJECT_ClASS_ID_OF(  SourcedContentVariable) ) ; 

REQ  Subordinates! { SUBORDINATE_ID_OF( Block) }+) ; 

PERM  Posit ion {ANY_VALUE) ; 

PERM  Dimensions {#horizontal{  #f ixed{ANY_VALUE) } , 
#vertical{#fixed{ANY_VALUE) ) } ; 

PERM  Application-comments! "SourcedContentVariable" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Border ! ANY_VALUE } ; 

PERM  Layout - path { ANY_VALUE ) ; 

) 

17.7.3.4.1 7Bas icHeaderFoo ter : ANY- FRAME ! 

GENERIC: 

REQ  Logical  - source ! ANY_VAHJE ) ; 

REQ  Application-comments ! "BasicHeaderFooter" ) ; 

SPECIFIC: 

REQ  Object-class !OBJECT_CLASS_ID_OF(  BasicHeaderFooter)}; 

REQ  Subordinates! !SUBORDINATE_ID_OF(Block) }+) ; 

PERM  Application-comments ! "BasicHeaderFooter" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Position! #fixed!ANY_VALUE} } ; 

PERM  Dimensions !#horizontal!  #fixed! ANY_VALUE} } , 

#vertical!#fixed!ANY_VALUE) ) } ; 

PERM  Layout-path! ' 270-degrees ') ; 

} 

17.7.3.4. ISBasicBody : ANY- FRAME ! 

GENERIC: 

REQ  Application-comments ! "BasicBody" } ; 

SPECIFIC: 

REQ  Object-class !OBJECT_CLASS_ID_OF(  BasicBody)}; 

REQ  Subordinates! !SU30RDINATE_ID_0F(Block) )+} ; 

PERM  Application-comments ! "BasicBody" } ; 

SPECIFIC_AND_GENERIC : 

PERM  Position!#fixed{ANY_VALUE} } ; 

PERM  Dimensions!#horizontal!  #fixed!ANY_VALUE) } , 

#vertical!#f ixed!ANY_VALUE} } } ; 

PEEIM  Layout-path!  ' 270-degrees '} ; 

} 

17.7.3.4.19Block:Am-LAY0UT! 

GENERIC: 
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REQ  Object-type{BLOCK) ; 

REQ  Content-architecture-class { $FC  j $PC  | $FPC  j $FPR  j $FPG) ; 
PERM  Content-portions {ANY_VAHJE} ; 

REQ  Application-comments { "Block" } ; 

PERM  Resource { ANY_VALUE ) ; 

SPECIFIC: 

REQ  Content-architecture-class {ANY_VALUE} ; 

PERM  Position{#fixed{ANY_VALUE) } ; 

PERM  Dimensions {#horizontal { #f ixed{ANY_VALUE} ) , 
#vertical{#fixed{ANY_VALUE} ) } ; 

PERM  Initial-offset{ANY_VALUE) ; 

PERM  Formatting- indicator {ANY_VALUE) ; 

PERM  Graphic-rendition{ANY_EXCEPT  26, 

Variable  spacing 

50}  ; 

Not  variable  spacing 
PERM  Graphic-character-set {ANY_VALUE} ; 

PERM  Application-comments { "Block" ) ; 

SPECIFIC_AND_GENERIC : 

PERM  Transparency { ANY_VALUE } ; 

PERM  Colour{ANY_VALUE} ; 

PERM  Border { ANY_VALUE } ; 

PERM  Presentation-style { STYLE_ID_OF(PStylel  | PStyle2  j PStyleS  | 
PStyle4} ; 

) 

17.7.4  Layout  style  constraints 

Note:  This  section  has  not  been  aligned  with  the  logical  and  layout 
constraint  objects  defined  in  sections  17.7.2  and  17.7.3. 

17.7.4. IFactors  constraints 

FACTOR  ANY -LAYOUT -STYLE  { 

REQ  Layout- style- identifier {ANY_VALUE) ; 

PERM  User-visible-name {ANY_VALUE} ; 

PERM  User-readable-comments {ANY_VALUE} ; 

) 

17.7.4.2Constituent  constraints 

17.7.4.2.lLStylel: ANY - LAYOUT - S TYLE { 

--  Used  for  LogDoc  only  -- 

REQ  Layout-obj ect-class {OBJECT_CLASS_ID_OF(Laydoc) ) ; 

) 

17.7.4.2. 2LStyle2 : ANY- LAYOUT- STYLE { 

--  Used  for  PageNumber  only  -- 
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PERM  Block-alignment! ANY_VALUE} ; 

PERM  Concatenation{ANY_VALUE) ; 

PERM  Indivisibility{ANY_VALUE} ; 

PERM  Layout-category {ANY_VALUE} ; 

PERM  Layout-object-class! ANY_VALUE) ; 

PERM  New-layout-object!ANY_VALUE} ; 

PERM  Same-layout-object!ANY_VALUE) ; 

PERM  Offset!ANY_VALUE) ; 

PERM  Separation ! ANY_VALUE } : 

) 

1 7 . 7 . 4 . 2 . 3LS ty le3 : ANY- LAYOUT - STYLE ! 

--  Used  for  Passage,  Paragraph,  Niambered  Segment, 
--  FNote  and  FNBody  only  -- 
PERM  Indivisibility!ANY_VALUE) ; 

PERM  Layout -object-c lass !ANY_VALUE} ; 

PERM  New- layout - ob j ec  t ! ANY_VALUE ) ; 

PERM  Same- layout-obj ect ! AJJY_VALUE } ; 

PEEIM  Synchronization!ANY_VALUE}  ; 

} 

1 7 . 7 . 4 . 2 . 4LS ty le4 : ANY - LAYOUT - STYLE ! 

--  Used  for  Number  only  -- 
PERM  Block- al ignment !ANY_VALUE} ; 

PERM  Concatenation!ANY_VALUE} ; 

PERM  Indivisibility!ANY_VALUE} ; 

PERM  Layout -category!ANY_VALUE) ; 

PERM  Layout-object-class !ANY_VALUE} ; 

PERM  New-layout-object!ANY_VALUE} ; 

PERM  Same - layout - obj ec t ! ANY_VALUE ) ; 

PERM  Offset !ANY_VALUE } ; 

PERM  Separation! ANY_VALUE} ; 

PEEIM  Synchronisation! ANY_VALUE)  ; 

} 

17.7.4.2. 5LStyle5 : AITY- LAYOUT-  STYLE ! 

--  Used  for  BodyText  only  -- 
PERM  B lock- a 1 ignment !ANY_VALUE} ; 

PERM  Concatenation! ANY_VALUE ) ; 

PERM  Indivisibility!ANY_VALUE} ; 

PERM  Layout - category !ANY_VALUE} ; 

PERM  Layout-object-class !ANY_VALUE} ; 

PERM  New- layout - ob j ec t ! ANY_V ALUE } ; 

PERM  Same-layout-object!ANY_VALUE} ; 

PERM  Offset!ANY_VALUE} ; 

PERM  Separation! ANY_V ALUE} ; 

PERM  Synchronisation! ANY_V ALUE } ; 

PERM  Fill-order!ANY_VALUE) ; 

} 
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17.7.4.2. 6LS  ty  le6 : ANY-  LAYOUT  - STYL,E  { 

Used  for  BodyRaster  and  BodyGeometric  only  -- 
PERM  Block-aligninent{ANY_VALUE}  ; 

PERM  Indivi s ib 1 1 i ty { ANY_VALUE ] ; 

PERM  Layout - category {ANY_VALUE) ; 

PERM  Layout-object-class{ANY_VALUE) ; 

PERM  New- layout - ob j ec t { ANY_VALUE } ; 

PERM  Same - layout - obj ec t { ANY_VALUE) ; 

PERM  Offset { ANY_VALUE } ; 

PERI-I  Separation(ANY_VALUE}  ; 

PERM  Synchronisation{ANY_VALU£) ; 

) 

17.7.5  Presentation  style  constraints 

Note:  This  section  has  not  been  aligned  with  the  logical  and  layout 
constraint  objects  defined  in  sections  17.7.2  and  17.7.3. 

17 . 7 . 5 . IMacro  definitions 

DEFINE ( C - PRES - ATTR , " 

PERM  Alignment {ANY_VALUE } : 

PERM  Character- fonts {ANY^VALUE) ; 

PERM  Character-orientation{$BASIC~CHAR-ORIENTATION  | 
$NON-BASIC-CHAR-ORIENTATION) ; 

PERM  Character-path! $BASIC~CHAR-PATH  ! $NON- BASIC- CHAR- PATH ) ; 

PERM  Character-spacing! ANY_VALUE) ; 

PERM  Code-extension-announcers ! $CODE-EXT-ANNOUNCERS } ; 

PERM  First-line-offset!ANY_VALUE) ; 

PERM  Formatting- indicator !ANY_VALUE} ; 

PERM  Graphic-character-sets !$BASIC-CHAR-SET  [ $NON-BASIC-CiiAR-SET)  ; 
PERM  Character-subrepertoire ! $BASIC-SUBREPERTOIRES  | 

$NON- BASIC -SUBREPERTOIRES) ; 

PERM  Graphics-rendition!ANY_EXCEPT  'variable-spacing' , 
'not-variable-spacing' } ; 

PERM  Indentation! ANY_VALUE) ; 

PERM  Initial-offset!ANY_VALUE} ; 

PERM  Itemization!ANY_VALUE) ; 

PERM  Kerning- offset ! ANY_VALUE } ; 

PERM  Line - layout -table! ANY_VALUE ) ; 

PERM  Line-progression!ANY_VALUE) ; 

PERM  Line-spacing!ANY_VALUE} : 

PERM  Orphan- size! ANY_VALUE ) ; 

PER!!  Pairwise -kerning ! ANY_VALUE } ; 

PERM  Proportional-line-spacing!ANY_VALUE) ; 

PERM  Widow- s ize ! ANY_VALUE ) ; ") 

DEFINE (R-PRES -ATTR, " 

PERM  Pel-path! ' 0-degrees ' | '270-degrees'); 

PERM  Line-progression! ' 0-degrees ' | '270-degrees'); 
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PERM  Pel- spac ing { ANY_INTEGER  <=1200}; 

DIS  Spac  ing- ratio  { ANY__VALUE ) ; 

PERM  C 1 ipp ing { ANY_VALUE ) ; 

PERM  Image -dimens ions {ANY_VALUE) ; ") 

DEFINE (G- PRES  - ATTR, " 

PERM  Ge  ome  t r ic - graph ics-encoding- announc  e r 

{ #VDC - typ  e { ANY_VALUE } , 

#Integer-precision{ 16  j 32}, 

#Real-precision{ { 0 9 23}  | {1  16  16}}, 

#Index-precision{ 8 j 16}, 

#Colour-precision{ 8 j 16}, 

#Colour-index-precision{ 8 | 16}, 

#Maximum- CO lour- index {ANY_VALUE} , 

#Co lour -value- extent {ANY_VALUE} , 

#Colour-selection-mode { ANY_VALUE} ; 

#VDC- integer-precision! 16  | 32}, 

#VDC-real-precision{ {0  9 23}  | {1  16  16}}  }; 

PERM  Line-rendition{ANY_VALUE} ; 

PERM  Marker-rendition! ANY_VALUE} ; 

PERM  Text-rendition 

{ 

#Fon t - 1 i s t ! ANY__VALUE } , 

#Gharacter-set-list!$BASIC-CHAR-SET  j $NON-BASIC-CHAR-SET] , 
#Character-coding-announcer !basic-7-bit  | basic-8-bit } , 
#Text-bundle - index !ANY_V ALOE} , 

#Text -font- index !ANY_VALUE} , 

#Text -precis ion !ANY_V ALOE} , 

#Charac ter- expans ion- fac tor !ANY_V ALOE) , 
#Character-spacing!ANY_VALUE} , 

#Text-colour!ANY_VALUE} , 

#Character-height!ANY_VALUE} , 

#Character-orientation! ANY_VALUE} , 

#Text-path!  ANn!_VALUE}  , 

#Text-alignment(^iNY_VALUE}  , 

#Character-set-index! ANY_VALUE} , 

#Tex  t - as  f ! ANY_VAL0  E } 

#Text-bundle - representation! ANY_VALUE}  ) I 
PERM  Filled-area-rendition 
{ 

#Fi 11 -bundle- index !ANY_VALUE} , 

#Interior- style {ANY_V ALOE} , 

#Fill -colour !ANY_VALUE} , 

#Ha t ch - index ! ANY_VALUE } , 

#Pattern- index ! 1 ..  8}, 

#Fil 1- reference -point !ANY_V ALOE} , 

#Pattern-size!ANY_VALUE} , 

#Pat tern- table -representation 
! #Pattern- table -index ! 1 8}, 

#Kv.unber”Of-columns!  1 ..  16}, 
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#Number-of-rows { 1 ..  16), 
#Local-colour-precision{0  j 1 j 8 | 16), 
#Colour-arry {ANY_VALUE)  ) , 
#Fill-asf{ANY_VALUE}  ); 

PERM  Edge-rendition{ANY_VALUE) , 

PERM  Colour-representation{ ANY_VALUE) ; 

PERM  Transparency-specif ication) ANY_VALUE) ; 

PERM  Transformation-specif ication{ ANY_VALUE} ; 

PERM  Region-of-interest-specif Ication  {ANY_VALUE) 

PERM  Picture-orientation{AMY_VALUE) ; 

PERM  Pic ture- dimens ions {AMY_VALUE) ; ") 

1? . 7 . 5 . 2Factor  constraints 

FACTOR: ANY- PRESENTATION- STYLE  { 

REQ  Presentation-style-identifier{ANY_VALUE) ; 
PERM  User-readable-comments (ANY_VALUE) ; 

PERM  User-vislble-name{ANY_VALUE) ; 

PERM  Border  { ANY__VALUE ) ; 

PERM  Colour { ANY_VALUE ) ; 

PERM  Transparency { ANY_VALUE ) ; 

) 

17.7.5.3Canstltuent  constraints 
17-7.5.3. IPStylel : ANY-PRESENTATION-STYLE { 

PERM  Presentation-Attributes {$C-PRES-ATTR) ; 

} 

17.7.5.3. 2PStyle2 : ANY-PRESENTATION-STYLE{ 

CASE  (Document-prof ile (Document-characteristics 

#Content“archicture-class) ) OF 
$FDA: 

REQ  Content-architecture-class { $CF) ; 

$PDA: 

REQ  Content-architecture-class {$CP) ; 

$FPDA: 

REQ  Content-architecture-class { $CFP} ; 

--  ENDCASE  -- 

PERM  Presentation-attributes { $C-PRES-ATTR) ; 

) 

17.7.5.3. 3PStyle3 : ANY- PRESENTATION- STYLE { 

REQ  Content-architecture-class { $RFP) ; 

PERM  Presentation-attributes { $R-PRES-ATTR) ; 

) 

17.7.5.3. 4PS tyle4 : ANY- PRESENTATION- STYLE { 
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REQ  Content-architecture-class { $GFP} ; 

PERM  Presentation-attributes { $G-PRES-ATTR) ; 

} 


17.7.6  Content  portion  constraints 


17.7.6.lCharacter  content  portion 

S PECI  FI  G_AND__GENERI  C : 

PERM  Content- identifier- layout {ANY_VALUE) ; 

PERM  Content-identifier-logical{ANY_VALUE) ; 

REQ  Type-of-coding{ 2 8360); 

PERM  Alternative-representation{ANY_VALUE) ; 

PERM  Content- information! 

{ #Charac  ter { ANY_VALUE } , 

--  Shared  Control  Functions  -- 
#CR{ ) . 

#GCC{AJ^Y_VALUE)  , 

#IGS{$BASIC- SUBREPERTOIRE  | $NON-BASIC-SUBREPERTOIRE) , 
Note: The  use  of  IGS  is  suppose  to  be  deprecated. 

#LF{ } , 

#PLD{ ) , 

#PLU{ ) , 

#SCS{ANY_VALUE) , 

#SGR{ANY_VALUE} , 

#SHS{0  I 1 I 2 I 3), 

#SLS{ANY_VALUE} , 

#SRS{ANY_VALUE} , 

#STAB { ANY_VALUE } , 

#SUB{ ) , 

#SVS{ANY_VALUE) , 

#VPB{ANY_VALUE} , 

#VPR{ANY_VALUE) , 

--  Layout  Control  Functions  -- 
#HPB{ANY_VALUE) , 

#HPR{ANY^VALUE) , 

#JFY{ANY_VALUE) , 

#SACS{ANY_VALUE) , 

#SRCS{ANY_VALUE} , 

#SS¥{ANY_VALUE} , 

--  Logical  Control  Functions  -- 
#BPH{ } , 

#NBH{ } , 

#PTX{ANY_VALUE} , 

--  Delimiter  Functions  -- 
#S0S{ ) , 

#SP{}, 

#ST{)  }; 
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17.7.6.2  Raster  graphics  content  portion 


DEFINE(T6, "{2  837  0)") 
DEFINE(T41D, "{2  837  1}") 
DEFINE(T42D, "{2  8 3 7 2}") 
DEFINE (BITMAP, "{2  8 3 7 3)") 


PERM 

PERM 

REQ 

PERM 

PERM 

{ 


PERM 


Content- identifier- logical {ANY_VALUE ) ; 

Content- identifier- layout {ANY_VALUE) ; 
Type-of-coding{$T6  | $T41D  j $T42D  \ $BITMAP}; 
Alternative-representation{ANY_VALUE} ; 
Coding-attributes { 

#Compression{ANY_VALUE) , 
#Nuinber-of-lines{ANY_VALUE) , 
#Nuinber-of-pels-per-line{  ANY_VALUE)  , 

}; 

Content- information! ANY  VALUE); 


17.7.6.3  Geometric  graphics  content  portion 

PERM  Content- identifier- logical {ANY_VALUE) ; 

PERM  Content-identifier-layout{ANY_VALUE) ; 

REQ  Alternative-representation! ANY_VALUE) ; 

PEBLM  Content -informat  ion  !ANY_VALUE)  ; 

--  Section  17.10.1  contains  a recommended  functional  subset  of 
the  CGM  standard  for  this  document  application  profile  -- 

17.7.7  Additional  usage  constraints 

No  other  usage  cons taints  are  currently  defined. 

17.8  Interchange  format 

Interchange  format  class  "A"  is  to  be  used  in  this  application 
profile,  as  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for 
Abstract  Syntax  Notation  One  (ASN.l),  as  defined  in  ISO  8825. 

17.8.1  ASN.l  generation  constraints 

The  following  are  additional  constraints  imposed  on  the  ASN.l 
generation  beyond  those  defined  in  ISO  8824  and  ISO  8825. 

17.8.2  Encoding  of  application  comments 

ISO  8613-5  define  the  encoding  of  the  attribute  Application 
Comments  as  an  octet  string.  This  document  application  profile 
requires  that  the  encoding  within  that  octet  string  be  in 
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accordance  with  the  ASN.l  syntax  specified  in  the  following 
module  definition. 


NISTDAPSpecif ication 
DEFINITION: :=BEGIN 

EXPORTS  Application-Comments -Encoding; 


Application-Comments-Encoding: :=SEQUENCE  { 

Cons traint -name [ 0 ] IMPLICIT  PrintableS tring 
External - data [ 1 ] EXTERNAL) 

END 

17.8.3  Encoding  of  raster  content  information 


The  encoding  of  raster  content  information  in  the  bitmap  encoding 
scheme  is  that  specified  in  clause  9.3  of  the  raster  graphics 
content  architecture  part  of  the  base  standard.  The  encoding  of 
the  code  words  in  the  Group  4 facsimile  encoding  scheme  is  such 
that  the  first  or  only  bit  of  the  first  code  word  shall  be  placed 
in  the  most  significant  bit  of  the  first  octet.  Subsequent  bits 
of  the  first  and  following  code  words  are  placed  in  the  direction 
of  less  significant  bits  in  the  first  and  following  octets. 

17.9  GSS/RSS  proforma 

17.9.1  Generator  support  statement  proforma 


Note:  This  section  is  being  written  in  conjunction  with  the 
ODA  document  application  profile  International 
alignment  activity  in  PAGODA. 

17.9.2  Receiver  support  statement  proforma 

Note:  This  section  is  being  written  in  conjunction  with  the 
ODA  document  application  profile  International 
alignment  activity  in  PAGODA. 


17.10 


Informative  Recommendations 


17.10.1  ISO  8632  (CGM)  constraints  for  this  DAP 


It  is  recommended  that  geometric  graphics  content  information 
contain  only  those  elements  listed  in  this  portion  of  the 
agreements,  in  addition  to  the  constraints  imposed  by  ISO  8613-8. 
It  is  believed  that  this  subset  of  the  CGM  is  sufficiently  widely 
implemented  to  enable  interworking  of  geometric  graphics  for 
application  conforming  this  dociament  application  profile. 

The  content  Information  of  a content  portion  description  that 
conforms  to  this  content  architecture  is  an  ASN.l  octet  string 
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representing  a Computer  Graphics  Metafile  (CGM)  conforming  to  the 
following  constraints: 

a)  Conform  to  part  1 of  the  ISO  8632  standard; 

b)  Conform  to  the  binary  encoding  defined  in  part  3 of  the 
ISO  8632  standard; 

c)  Consist  of  a single  picture; 

d)  Conform  to  the  ISO  pdISP  FCG13,  except  as  noted  with 
respect  to  font  and  colour  table  support; 

e)  Generalized  Drawing  Primitives  are  ignored; 

f)  ESCAPE  Elements  are  ignored; 

g)  External  Elements  may  be  ignored. 

The  following  list  is  a description  of  the  constraints  for  each 
of  the  CGM  elements.  Where  an  element  has  parameters, 
recommended  constraints  on  the  values  are  given.  The  symbol 

indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  ISO  8613-8  concerning  mandatory 
elements,  parameters  must  be  fulfilled. 

ly.lO.l.lDelimiter  elements 

Begin  MetafileSee  Note  1 
End  Metafile- - 
Begin  PictureSee  Note  1 
Begin  Picture  Body-- 
End  Picture-- 

17 . 10 . 1 . 2Metaf ile  description  elements 
Metafile  Versionl 

Metafile  DescriptionSee  Notes  1,  2 
Real  Precision(0 , 9 , 23) , (1,16,16) 

Index  Precisionl6 
Colour  Precision8,  16 
Colour  Index  Precision8,  16 
Maximum  Colour  IndexO-255 

Colour  Value  Extent3- tuple  in  range  (0,32767) 

Metafile  Element  List-1,1 
Metafile  Defaults  ReplacementSee  Note  3 
Font  ListSee  Note  4 
Character  Set  ListSee  Note  5 

Character  Coding  Announcer (Editor)  Above  FCG12 
basic  7-bit,  basic-8-bit 

17 . 10 . 1 . 3Picture  descriptor  elements 

VDC  Extent- - 
Background  Colour- - 
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17 . 10 . 1 .4Control  elements 


Transparency- - 
Clip  Rectangle- - 
Clip  Indicator-- 

17 . 10 . 1 . 5Graphical  primitive  elements 

Polyline  See  Note  7 
Polymarker See  Note  7 
Text  See  Note  2 
Polygon  See  Note  7 
Polygon  SetSet  Note  7 
Rectangle- - 
Circle 

Circular  Arc  Centre- - 
Circular  Arc  Centre  Close-- 
Ellipse 

Elliptical  Arc-- 
Elliptical  Arc  Close-- 

17.10.1. 6Attribute  elements 

Line  Typel-5 
Line  Width- - 
Line  Colour- - 
Marker  Typel-5 
Marker  Size-- 
Marker  Colour- - 
Text  Font  Index- - 

Text  Precision- - (Editor)  Above  FCG12 

Character  Expansion  Factor- - (Editor)  Above  FCG12 

Character  Spacing- - (Editor)  Above  FCG12 

Text  Colour- - 

Character  Height- - 

Character  Orientation- - 

Text  Path- - (Editor)  Above  FCG12 

Text  Alignmenthorizontal : normal,  left,  centre,  right 

vertical:  normal,  top,  cap,  half,  base,  bottom 
Character  Set  Indexl , 2(Editor)  Above  FCG12 
Interior  StyleO,  1,  3,4 
Fill  Colour-- 
Hatch  Indexl -6 

Colour  Table  Specif icationSee  Notes  8,  9 

17 . 10 . 1 . 7Extemal  Elements 

Message  No  action 
Application  DataSee  Note  1 
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Note  1 

Note  2 

Note  3 

Note  4 

Note  5 

Note  6 

Note  7 

Note  8 


Support  will  be  provided  for  strings  with  a length  up 
to  256  octets,  except  for  data  records  which  will 
support  strings  with  a length  up  to  32767  octets. 

The  METAFILE  DESCRIPTION  string  parameter  will  be  used 
to  include  the  sub -string  "ISO  FCG12"  to  label  the 
content  information  as  conforming  to  this  agreement. 

In  addition,  generator  of  content  are  encouraged  to 
append  a sub-string  that  identifies  the  company  and 
product  that  produced  the  CGM. 

The  METAFILE  DEFAULTS  REPLACEMENT  element  shall  not  be 
partitioned.  No  part  of  the  element  will  be 
partitioned.  Multiple  occurrences  of  the  MDR  element 
may  be  used  to  avoid  the  need  for  partitioning.  The 
MDR  element  must  appear  in  the  CGM  to  establish  the 
defaults  for  TEXT  PRECISION  and  any  other  elements 
whose  defaults  are  different  than  those  specified  in 
ISO  8632-1  and  -3. 

The  only  fonts  that  may  be  specified  are  those 
specified  in  the  document  profile.  The  font  list  must 
be  in  the  same  order  as  that  specified  in  the  document 
profile . 

The  only  character  sets  that  may  be  specified  are  ISO 
6937/2  (0,  4/0)  and  ISO  8859/1  (0,  4/2).  The  order  of 
the  specification  of  these  characters  must  match  the 
order  specified  in  the  document  profile. 

The  Scale  Factor  parameter  of  SCALING  MODE  element  is 
always  a 32-bit  floating  point  value,  even  when  the 
REAL  PRECISION  has  selected  fixed  point  for  other  real 
numbers.  It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  is  when  fixed 
point  has  been  selected.  Its  precision  shall  be 
(0,9,23). 

The  minimum  support  for  the  length  of  point  lists  is 
1024  elements. 

The  COLOUR  TABLE  element  has  an  unspecified  effect  when 
it  appears  in  a picture  subsequent  to  any  graphical 
primitives.  The  COLOUR  TABLE  element  shall  appear 
prior  to  any  graphical  primitive  elements  to  assure 
that  interpreting  systems  without  dynamic  colour  update 
can  render  the  intended  effect. 
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Note  9: 


The  minimum  support  for  the  length  of  the  Colour  List 
parameter  in  the  COLOUR  TABLE  element  is  61.  This  will 
support  a 63  entry  colour  table. 

17.10.2  Registration  of  entities 

The  NIST  OSI  Implementor's  Workshop  as  allocated  a name  space  to 
the  NIST  ODA  SIC.  The  name  space  is  intended  to  be  used  by  the 
NIST  ODA  SIG  for  registration  of  entities  within  its  domain.  For 
example,  object  identifiers  for  ODA  document  application 
profiles.  Other  possibilities  include  private  content  or  font 
identifiers.  The  name  space  is  Identified  by  the  following  path 
specification: 

{ISO(l)IdentifiedOrganization(3)OIW(14)ODAISG(ll) ) 

To  facilitate  the  management  of  this  name  space,  factorization  of 
Identifiers  is  required.  The  ODASIG  level  of  the  path  shall 
contain  a subordinate  level  for  ODA  document  application 
profiles,  with  identifier  value  0.  Other  subordinates  at  this 
level  may  be  defined  in  the  future.  Subordinate  to  the  document 
application  profiles  level  is  a level  for  each  functional  level 
of  document  application  profile.  At  present,  two  levels  have 
been  identified  for  the  Level  3 DAP  (identifier  value  of  0)  and 
the  Level  2 DAP  (identifier  value  of  1).  Subordinate  to  this 
level  is  an  identifier  for  each  Instance  of  a document 
application  profile  defined  at  this  level  of  profile. 

The  NIST  Level  2 DAP  defined  in  by  this  implementation  agreements 
document  is  defined  by  the  object  identifier: 

{ ISO(l)IdentifiedOrganization(3)OIW(14)ODASIG(ll) 
DAPs(0)Level2(l)Alpha(0) } 

In  order  to  reduce  the  verbosity  of  this  representation,  it  is 
recommended  that  the  following  notation  be  used,  in  place  of  the 
complete  description: 

{1  3 14  11  0 1 0} 

17.10.3  Conveyance  of  ODA  over  CCITT  X. 400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be 
encoded  for  transmission  over  a CCITT  X. 400- 1984  service. 

17.10.3.1P2  protocol  encoding 

An  ODA  document  will  be  transferred  as  a single  body  part  with 
tag  12: 
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oda  [12]  IMPLICIT  OCTET  STRING 

The  content  of  the  OCTET  STRING  will  contain  an  ASN.l/BER  encoded 
segment  with  a value  of  type  OdaBodyPart,  which  is  a SEQUENCE 
containing  the  OdaBodyPartParameters  and  OdaData  components: 

OdaBodyPart  ; :=  SEQUENCE! 

OdaBodyPartParameters , 

OdaData  ) 

The  OdaBodyPartParameters  and  the  OdaData  components  are  each 
aligned  to  Annex-E  of  ISO  8613-1  and  CCITT  T. 411-1988. 

The  OdaBodyPartParameters  component  is  a SET  containing  the 
document-application-profile  and  the  document-architecture-class 
identifiers : 

OdaBodyPartParameters  : :=  SET  { 

document -application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFER, 
document -architecture -class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0) , 
processable  (1), 
formatted-processable  (2)  )) 

The  OdaData  component  is  a SEQUENCE  OF  Interchange-Data-Element 
as  defined  by  ISO  8613-5: 

OdaData  : :=  SEQUENCE  OF  Interchange-Data-Element 

17.10.3.2P1  protocol  encoding 

The  Encoded  Information  Type  (EIT)  for  an  ODA  body  part  will  be 
the  'ODA'  bit,  bit  10,  The  'Undefined'  bit,  bit  0,  must  be  set 
as  well.  An  MTA  can  test  for  deliverability  on  the  basis  of  the 
presence  of  an  ODA  body  part. 

The  EITs  are  unable  to  record  the  document-application-profile. 
Also,  the  G3Fax  EIT  bit  must  not  be  set  even  if  the  ODA  document 
contains  G3Fax  content  portions. 

17.10.4  Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between 
Standard  Generalized  Markup  Language  (ISO  8879,  SGML)  based 
systems  and  systems  based  on  this  ODA  document  application 
profile  is  by  means  of  exchanging  a document  representation 
conforming  to  these  agreements  in  an  encoded  form  of  the  SGML 
language  known  as  the  Office  Document  Language  (ODL) . ODL  is  a 
standardized  SGML  application  for  representing  documents 
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conforming  to  the  ODA  base  standard.  Such  a representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF) 
supported  by  this  document  application  profile. 
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18.  NETWORK  MANAGEMENT 


Editor's  Note:  There  is  currently  no  text  for  subsections  8,  9, 
and  10  (described  below) . 

Editor's  Note:  The  notes  in  this  section  are  meant  to  be 
placeholders  for  future  text.  They  are  included 
here  to  reflect  SIG  activity  in  these  areas. 

18,1  INTRODUCTION 


Within  the  community  of  OSI  researchers,  users,  and  vendors,  there  is 
a recognized  need  to  address  the  problems  of  initiating,  terminating, 
monitoring,  and  controlling  communication  activities  and  assisting  in 
their  harmonious  operation,  as  well  as  handling  abnormal  conditions. 
The  activities  that  address  these  problems  are  collectively  called 
network  management. 

Network  management  can  then  be  viewed  as  the  set  of  operational  and 
administrative  mechanisms  necessary  to: 

a.  bring  up,  enroll,  and/or  alter  network  resources, 

b.  keep  network  resources  operational, 

c.  fine  tune  these  resources  and/or  plan  for  their  expansion, 

d.  manage  the  accounting  of  their  usage,  and 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management 
activities  in  at  least  the  following  five  functional  areas: 
configuration  management,  fault  management,  performance  management, 
accounting  management,  and  security  management.  In  order  to 
accomplish  these  management  activities,  information  must  be  exchanged 
among  management  processes.  Managing  processes  have  the 
responsibility  for  carrying  out  one  or  more  management  activities. 
Agent  processes  act  on  behalf  of  managing  processes,  forwarding 
notifications  from  and  manipulating  managed  objects. 

In  this  section,  there  are  Implementation  Agreements  (lA's)  for 
providing  interoperable  OSI  management  information  communication 
services  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information,  or  pointers  to  other  sections  of  this  document 
or  other  documents  where  such  additional  agreements  appear. 

These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a multivendor 
environment.  Therefore,  the  goal  is  to  ensure  that  a management 
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system  built  by  one  vendor  can  manage  network  objects  built  by  another 
vendor . 

In  progressing  work  on  OSI  management  in  the  NIST/OSI  NMSIG,  the  OSI 
management  framework  specified  in  ISO  7498/Part  4 (as  presented  in 
reference  [FRMWK])  shall  be  used  as  the  basis  for  concepts  and 
terminology  relevant  (a)  to  OSI  management  activities,  and  (b)  to 
management  services  supported  by  OSI  management  protocols.  Thus, 
these  agreements  are  based  on,  and  employ,  protocols  developed  in 
accord  with  the  OSI  Reference  Model.  Furthermore,  they  attempt  to 
eliminate  ambiguities  in  interpretations  of  management  protocol 
standards  and  management  information  standards. 


18.1.1 References 

The  following  documents  are  referenced  in  the  statements  of  the 
agreements  relating  to  NIST/OSI  network  management. 

OSI  Systems  Management  References: 


[ADDRMVP]  ISO/IEC  9596/DAD  2,  Common  Management  Information 
Protocol  Specification:  Addendum  2 (Add/Remove 
Protocol),  ISO/IEC  JTC1/SC21,  1 February  1990. 


[ADDRMVS]  ISO/IEC  9595/DAD  2,  Common  Management  Information 

Service  Definition:  Addendum  2 (Add/Remove  Service) , 
ISO/IEC  JTC1/SC21,  1 February  1990. 


[ALS]  ISO/IEC  DIS  9545,  Information  Processing  Systems  - Open 

Systems  Interconnection  - Application  Layer  Structure, 
15  March  1989. 

[AMWD]  Information  Processing  Systems  - Open  Systems 

Interconnection  - Accounting  Management  Working 
Document  (Third  Version),  ISO/IEC  JTC1/SC21  N4085, 
November  1989. 

[ARF]  ISO/IEC  2nd  DP  10164-4,  Information  Processing  Systems 

- Open  Systems  Interconnection  - Systems  Management  - 
Part  4:  Alarm  Reporting  Function,  ISO/IEC  JTC1/SC21 
N4070,  November  1989. 

[CANGETP]  ISO/IEC  9596/DAD  1,  Common  Management  Information 
Protocol  Specification:  Addendum  1 (CancelGet 
Protocol),  ISO/IEC  JTC1/SC21,  1 February  1990. 
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[CANGETS] 

ISO/IEC  9595/DAD  1,  Common  Management  Information 
Service  Definition:  Addendum  1 (CancelGet  Seirvice)  , 
ISO/IEC  JTC1/SC21,  1 February  1990. 

[CDTF] 

ISO/IEC  DP  10164-*,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  x:  Confidence  and  Diagnostic  Testing  Function 
(First  Working  Draft),  ISO/IEC  JTC1/SC21  N4078, 

December  1989. 

[CHIP] 

ISO/IEC  9596-2,  Information  Processing  Systems  - Open 
Systems  Interconnection  - Management  Information 
Protocol  Specification  - Part  2:  Common  Management 
Information  Protocol,  6 December  1989. 

[CMIS] 

ISO/IEC  9595-2,  Information  Processing  Systems  - Open 
Systems  Interconnection  - Management  Information 

Service  Definition  - Part  2:  Common  Management 
Information  Service,  6 December  1989. 

[CMO] 

Information  Processing  Systems  - Open  Systems 
Interconnection  - Working  Draft  of  the  Configuration 
Management  Overview,  ISO/IEC  JTC1/SC21  N3311,  16 

January  1989. 

[DMI] 

ISO/IEC  DP  10165-2,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Structure  of  Management 
Information  - Part  2:  Definition  of  Management 
Information,  ISO/IEC  JTC1/SC21  N4072,  December  1989. 

[ERMF] 

ISO/IEC  2nd  DP  10164-5,  Information  Processing  Systems 
- Open  Systems  Interconnection  - Systems  Management  - 
Event  Report  Management  Function,  ISO/IEC  JTC1/SC21 
N4071,  November  1989. 

[FMWD] 

Information  Processing  Systems  - Open  Systems 
Interconnection  - Systems  Management  - Fault  Management 
Working  Document,  ISO/IEC  JTC1/SC21  N4077,  December 
1989. 

[FRMWK] 

ISO  7498-4,  Information  Processing  Systems  - Open 
Systems  Interconnection  - Basic  Reference  Model  - Part 
4:  Management  Framework,  1989. 

[GDMO] 

ISO/IEC  DP  10165-4,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - SMI  - Part  4: 

Guidelines  for  the  Definition  of  Managed  Objects, 
ISO/IEC  JTC1/SC21  N4065,  20  November  1989. 
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[LCF] 


[MIM] 


[MSF] 


[OMF] 


[OSIMIL] 


[PMWD] 


[RMF] 


[SARF] 


[SATF] 


[SMF] 


ISO/IEC  DP  10164-6,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  6:  Log  Control  Function,  ISO/IEC  JTC1/SC21  N4063, 
November  1989. 

ISO/IEC  DP  10165-1,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Managemeiit  Information 
Services  - Structure  of  Management  Information  - Part 
1;  Management  Information  Model,  ISO/IEC  JTC1/SC21 
Nxxxx,  February  1990. 

ISO/IEC  DP  10164-'*,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  x;  Measurement  Summarization  Function  (First 
Working  Draft),  ISO/IEC  JTC1/SC21  N4081,  December  1989. 

ISO/IEC  2nd  DP  10164-1,  Information  Processing  Systems 

- Open  Systems  Interconnection  - Systems  Management  - 
Part  1;  Object  Management  Function,  ISO/IEC  JTC1/SC21 
N4067,  23  November  1989. 

Management  Information  Library  (MIL)  - Revision  3.0, 

OSI  MIB  VJorking  Group  of  NMSIG  of  NIST/OSI  Implementors 
Workshop,  10  March  1990. 

Information  Processing  Systems  - Open  Systems 
Interconnection  - Performance  Management  Working 
Document  (Fifth  Draft),  ISO/IEC  JTC1/SC21  N4079, 
December  1989. 

ISO/IEC  2nd  DP  10164-3,  Information  Processing  Systems 

- Open  Systems  Interconnection  - Systems  Management  - 
Part  3:  Relationship  Management  Function,  ISO/IEC 
JTC1/SC21  N4069,  23  November  1989. 

ISO/IEC  DP  10164-7,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  7:  Security  Alarm  Reporting  Function,  ISO/IEC 
JTC1/SC21  N6064,  20  November  1989. 

ISO/IEC  DP  10164-*,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  x;  Security  Audit  Trail  Function,  ISO/IEC 
JTC1/SC21  N4092,  20  November  1989. 

ISO/IEC  2nd  DP  10164-2,  Information  Processing  Systems 

- Open  Systems  Interconnection  - Systems  Management  - 
Part  2:  State  Management  Function,  ISO/IEC  JTC1/SC21 
N4068 , 23  November  1989. 
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[SMO] 

[SMWD] 

[WMF] 

Other  OSI 
[ACSEP] 

[ACSES] 

[ASNl] 

[BER] 

[DIR] 

[PPS] 

[PSD] 

[ROSEP] 


ISO/IEC  2nd  DP  10040,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management 
Overview,  ISO/IEC  JTC1/SC21  N4066,  December  1989. 

Information  Processing  Systems  - Open  Systems 
Interconnection  - Systems  Management  - OSI  Security 
Management  Working  Document  - 7th  Draft,  ISO/IEC 
JTC1/SC21  N4091,  15  November  1989. 

ISO/IEC  DP  10164-*,  Information  Processing  Systems  - 
Open  Systems  Interconnection  - Systems  Management  - 
Part  x:  Workload  Monitoring  Function,  ISO/IEC 
JTC1/SC21  N4080,  December  1989. 


References : 

ISO  8650,  Information  Processing  Systems  - Open  Systems 
Interconnection  - Protocol  Specification  for  the 
Association  Control  Service  Element  (Revised  Final  Text 
of  DIS  8650),  ISO/IEC  JTC1/SC21  N2327,  21  April  1988. 

ISO  8649,  Information  Processing  Systems  - Open  Systems 
Interconnection  - Service  Definition  for  the 
Association  Control  Service  Element  (Revised  Final  Text 
of  DIS  8649),  ISO/IEC  JTC1/SC21  N2326,  21  April  1988. 

ISO  8824,  Information  Processing  Systems  - Open  System 
Interconnection  - Specification  of  Abstract  Syntax 
Notation  One  (ASN.l),  19  May  1987. 

ISO  8825,  Information  Processing  Systems  - Open  Systems 
Interconnection  - Basic  Encoding  Rules  for  Abstract 
Syntax  Notation  One  (ASN.l),  19  May  1987. 

ISO  9594  - Information  Processing  Systems  - Open 
Systems  Interconnection  - The  Directory,  1988. 

ISO/IEC  DIS  8823,  Information  Processing  Systems  - Open 
Systems  Interconnection  - Connection  Oriented 
Presentation  Protocol  Specification,  ISO/IEC  JTC1/SC21 
N2336,  5 April  1988. 

ISO/IEC  Final  Text  of  DIS  8822,  Information  Processing 
Systems  - Open  Systems  Interconnection  - Connection 
Oriented  Presentation  Service  Definition,  ISO/IEC 
JTC1/SC21  N2335,  5 April  1988. 

ISO/IEC  9072-2  - Information  Processing  Systems  - Text 


18-5 


March  1990  (Working) 


Communications  - Remote  Operations  Part  2:  Protocol 
Specification,  19  September  1989. 

[ROSES]  ISO/IEC  9072-1,  Information  Processing  Systems  - Text 
Communications  - Remote  Operations  Part  1:  Model, 
Notation  and  Service  Definition,  19  September  1989. 


Other  References 


[MAP30]  MAP  3.0  Network  Management  Specification,  August  1988. 

Editor's  Note:  Section  editors  whose  text  cites  these 
references  will  keep  them  up-to-date  and 
will  provide  additional  references  as 
needed,  e.g.,  most  recent  ISO  "N"  number 
and  date  will  be  provided. 


18,2  SCOPE  AND  FIELD  OF  APPLICATION 

The  purpose  of  this  section  (sec.  18),  is  to  provide  implementation 
agreements  that  will  enable  independent  vendors  to  supply  customers 
with  a diverse  set  of  networking  products  that  can  be  managed  as  part 
of  an  integrated  environment.  Where  possible,  these  agreements  are 
based  upon  OSI  Network  Management  standards. 

Due  to  the  broad  scope  of  the  subject,  and  given  that  OSI  Management 
standards  are  still  evolving,  it  is  reasonable  to  assume  that  a 
comprehensive  set  of  network  management  implementors  agreements  will 
take  a number  of  years  to  develop.  In  order  to  arrive  at  an  Initial 
set  of  implementation  agreements  in  a timely  fashion,  a phased 
approach  has  been  adopted. 

As  a first  step  in  this  phased  approach,  the  NMSIG  has  targeted  that 
the  initial,  Phase  1,  interim  agreements  will  be  completed  by 
December,  1989.  These  Phase  1 agreements  provide  limited 
interoperable  management  in  a heterogeneous  vendor  environment.  Ttiey 
are  the  cornerstone  of  our  eventual  comprehensive  inventory  of  OSI- 
compatible  management  agreements.  Furthermore,  these  initial 
agreements  allow  the  community  to  gain  experience  with  OSI  management 
standards  as  they  emerge. 

The  scope  of  the  problem  addressed  in  Phase  1 has  been  constrained  in 
several  ways.  The  sections  below  outline  the  nature  of  these 
constraints  and  thereby  serve  to  clarify  the  scope  and  field  of 
application  associated  with  this  version  of  the  implementors 
agreements  (December  1989).  Subsequent  phases  of  these  agreements 
(post  December  1989)  will  expand  the  scope  of  problems  addressed. 
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Editor's  Note:  The  following  phase  definitions  and  milestones 

represent  the  current  workplan  of  the  NMSIG.  The 
target  dates  are  the  earliest  dates  at  which  the 
milestones  could  possibly  be  accomplished  and  depend 
(in  part)  on  optimistic  assumptions  about  the  progress 
of  relevant  standards. 

The  scope  of  Phase  1 lA's  will  be  the  following: 

Management  Functions: 

Object  Management,  State  Management, 
Relationship  Management,  Error  Reporting  and 
Event  Control 

Management  Information: 

Information  Model,  Naming,  Guidelines  and 
Template  for  Defining  Managed  Objects 

Management  Communication: 

CMIS/P,  Association  Policies,  and  Services 
Required 

Management  Object: 

Support  Objects  required  for  above  and  14 
Managed  Object  Definitions  under  development 
by  the  OSl'  MIB  WG 

Conformance  Criteria: 

TBD  depending  on  the  progress  of  relevant  ISO 
documents . 

The  milestones  for  Phase  1 lAs  and  earliest  target 
dates  are: 

Milestone  A:  [12/89] 

Freeze  the  scope  of  Phase  1 and  approve  first 
draft  text  for  Ongoing  lAs  that  cover  all  of 
Phase  1 except  Managed  Objects  and 
Conformance  Criteria. 

Milestone  B:  [3/90] 

Add  the  Phase  1 Managed  Objects  to  the 
Ongoing  lAs . 

Milestone  C:  [6/90] 

Align  the  Ongoing  lAs  pertaining  to  Phase  1 
with  ISO  DIS  docunients . Add  conformance 
criteria  pertaining  to  Phase  I to  the  Ongoing 
lAs . 
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Milestone  D:  [9/90] 

Progress  the  Ongoing  lAs  pertaining  to  Phase 
1 into  Stable  lAs. 


The  preliminary  milestones  and  earliest  target  dates 
for  Phase  2 are: 

Milestone  E:  [3/90] 

Define  the  Scope  of  Phase  2 lAs. 

Milestone  F:  [9/90] 

Freeze  the  Scope  of  Phase  2 lAs  and  approve 
the  first  draft  text  covering  all  of  Phase  2. 

It  is  the  intention  of  the  NMSIG  to  freeze  the  content 
of  Phase  1 at  Milestone  A.  Only  those  changes  required 
to  align  with  the  ISO  DIS's  will  be  made. 

It  is  the  intention  of  the  NMSIG  to  define  Phase  2 
functionality  as  a compatible  superset  of  Phase  1. 

The  following  is  an  outline  of  the  information  provided  in  these 
agreements  (sec.  18): 

Section  18. 2--  SCOPE  AND  FIELD  OF  APPLICATION  (This  sec.):  This 
section  covers  several  areas.  Specifically: 

o Section  18.2.1  describes  the  relationship  between  these 
agreements  and  the  evolving  international  management 
standards . 

o Section  18.2.2.1  provides  a brief  overview  of  the 
management  architecture  described  in  the  standards 
documents . 

o Section  18.2.2.2  identifies  the  constraints  imposed  on 
Phase  1 of  these  agreements. 

o Section  18.2.2.3  addresses  migration  strategies 
regarding  subsequent  phases  of  these  agreements. 

o Section  18.2.2.4  addresses  interoperability  with 

systems  associated  with  other  management  specifications 
(including  MAP/TOP)  [MAP30] . 

o Section  18.2.3  presents  an  overview  of  the 

functionality  supported  by  Phase  1 of  these  agreements. 
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Section  18.3  --  STATUS:  This  section  describes  the  current  status 
of  these  agreements. 

Section  18.4  --  ERRATA:  Once  this  document  is  incorporated  into  a 
version  of  the  Stable  Implementation  Agreements  for  Open  System 
Interconnection  Protocols,  this  section  will  contain  corrections 
to  the  stable  management  agreements.  In  addition,  this  section 
documents  interim  resolutions  to  defects  found  in  the  management 
standards . 

Section  18.5  --  MANAGEMENT  FUNCTIONS:  This  section  documents 
agreements  pertaining  to  the  Systems  Management  Functions.  In 
addition,  it  identifies  agreements  pertaining  to  the  use  of  other 
application  service  elements  (e.g.  the  Common  Management 
Information  Service  Element  (CMISE)). 

Section  18.6  --  MANAGEMENT  COMMUNICATIONS:  This  section 
identifies,  in  detail,  the  following: 

o Agreements  on  Association  Policies 

o Agreements  on  the  Common  Management  Information 
Services  (CMIS)  offered. 

o Common  Management  Information  Protocol  (CMIP) 

agreements . 

o Agreements  pertaining  to  the  services  required  by  CMIP. 

Section  18.7  --  MANAGEMENT  INFORMATION:  This  section  is  based  on 
evolving  ISO  documents  [MIM]  and  [GDMO] , and  provides  tutorial 
material  and  agreements  for  management  information  related 
concepts  and  modelling  techniques.  Sub-sections  introduce  the 
information  model,  list  principles  for  naming  managed  objects  and 
attributes,  and  provide  guidelines  for  defining  management 
information. 

Managed  object  definitions  are  outside  the  scope  of  this  section, 
and  are  provided  in  the  Management  Information  Library  (MIL) . 

(The  MIL  is  produced  by  the  OSI  MIB  Working  Group,  a subgroup  of 
the  NMSIG.) 

Section  18.8  --  IMPLEMENTATION  PROFILES/CONFORMANCE  CLASSES: 

This  section  describes  the  implementation  prof iles/conformance 
classes  that  are  used  to  categorize  management  products.  At  the 
highest  level,  products  fall  into  two  broad  categories:  systems 
that  take  on  a managing  system  role  and  systems  that  take  on  an 
agent  system  role  representing  managed  objects.  (Refer  to  sec. 
18.2.2  for  further  clarification  regarding  these  categories.) 
Phase  1 of  these  agreements  defines  implementation 
profiles/conformance  classes  only  for  systems  that  take  on  an 
agent  system  role. 
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Editor's  Note:  The  NMSIG  intends  for  Phase  1 to  ensure  that  the 
interface  between  managing  processes  and  agent 
processes  is  adequately  specified,  thereby 
enabling  the  development  of  interoperable  managing 
processes  and  agent  processes.  It  is  believed 
that,  by  identifying  implementation 

profiles/conformance  classes  only  for  systems  that 
take  on  an  agent  system  role,  we  will  also  have 
sufficiently  identified  the  expected  behavior  of 
systems  that  take  on  a managing  system  role. 

Section  18.9  --  CONFORMANCE:  For  each  of  the  classes  identified 
in  section  18.8,  this  section  outlines  the  criteria  used  to 
determine  whether  or  not  a given  product  conforms  to  the  class 
specification  that  it  purports  to  be.  More  to  the  point,  in 
conjunction  with  Phase  1: 


o Systems  that  take  on  an  agent  system  role  will  be 

tested,  via  interactions  with  a test  managing  system  to 
ensure  that  they  appropriately  represent  those  managed 
objects  that  they  purport  to  represent. 

Editor's  Note:  Although  systems  that  take  on  a managing 
system  role  are  not  to  be  tested  for 
conformance  in  Phase  1 , it  is  believed  that 
market  presence  of  conformant  systems  that 
take  on  an  agent  system  role  will  provide  an 
adequate  climate  for  determining  the 
suitability  of  systems  that  take  on  a 
managing  system  role. 

Section  18.10  --  REGISTRATION  REQUIREMENTS:  This  section 
identifies  the  management  entities  that  must  be  registered.  This 
includes  a listing  of  those  managed  objects  that  must  be  defined 
in  order  to  satisfy  the  functional  requirements  outlined  in  the 
Phase  1 agreements. 

In  addition,  this  section  describes  the  mechanisms  used  to 
register  management  entities  and  the  means  by  which  one  can 
obtain  information  about  a registered  entity. 


18.2,1 Use  of  Evolving  Standards 

In  general,  it  is  the  intent  of  the  NMSIG  to  base  these 
implementors  agreements  on  existing  international  management 
standards . 
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Editor’s  Note:  Table  18.1  below  shows  the  relevant  standards 
documents  and  the  current  schedules  for 
progressing  these  documents  to  the  IS  status.  The 
table  describes  the  work  items  and  associated 
target  dates  approved  at  the  Sixth  SC  21/WG  4 
Meeting  in  Florence,  October  31  - November  9, 

1989. 
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Table  18.1.  RELEVANT  STANDARDS  DOCUMENTS  AND  THE  CURRENT 

SCHEDULES  FOR  PROGRESSING  THESE  DOCUMENTS  TO  IS 
STATUS 

Target  Dates 


Document 

DP 

DIS 

IS 

Management  Framework 

9/86 

6/87 

10/88 

Systems  Management  Overview 

7/90 

4/91 

Structure  of  Management  Information 

Part  1:  Management  Information  Model 

5/89 

1/90 

1/91 

Part  2:  Definition  of  Management 

7/90 

4/91 

Information 

Part  4:  Guidelines  for  the  Definition  of 

11/89 

1/91 

1/92 

Managed  Objects 

Common  Management  Information  Service 

Addendum  1:  CancelGet 

9/89 

1/90 

7/90 

Addendum  2 : Add/Remove 

9/89 

7/90 

Common  Management  Information  Protocol 

Addendum  1:  CancelGet 

9/89 

1/90 

7/90 

Addendum  2 : Add/Remove 

9/89 

7/90 

Configuration  Management 

Systems  Management  - Part  1: 

7/90 

7/91 

Object  Management  Function 

Systems  Management  - Part  2: 

7/90 

7/91 

State  Management  Function 

Systems  Management  - Part  3: 

7/90 

7/91 

Relationship  Management  Function 

Fault  Management 

Systems  Management  - Part  4: 

7/90 

7/91 

Alarm  Reporting  Function 

Systems  Management  - Part  5: 

7/90 

7/91 

Event  Report  Management  Function 
Systems  Management  - Part  *: 

7/90 

4/91 

4/92 

Confidence  and  Diagnostic  Testing 
Function 

Systems  Management  - Part  6: 

11/89 

7/90 

7/91 

Log  Control  Function 

Security  Management 

Systems  Management  - Part  7 : 

11/89 

7/90 

7/91 

Security  Alarm  Reporting  Function 
Systems  Management  - Part  *: 

7/90 

4/91 

4/92 

Security  Audit  Trail  Function 
Accounting  Management 

Systems  Management  - Part  *: 

7/90 

4/91 

4/92 

Accounting  Metering  Function 
Performance  Management 

Systems  Management  - Part 

7/90 

4/91 

4/92 

Workload  Monitoring  Function 

Systems  Management  - Part  *: 

7/90 

4/91 

4/92 
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Measurement  Summarization  Function 

Given  the  current  state  of  the  standards,  the  ongoing  Phase  1 
implementors'  agreements  are  based  on  documents,  some  of  which  are  not 
yet  at  the  DIS  level.  In  addition,  in  order  to  meet  the  stated 
objectives  of  the  Phase  1 agreements,  some  agreements  have  been  formed 
in  advance  of  the  availability  of  DP's  in  the  relevant  areas. 

As  the  relevant  standards  documents  progress  to  DIS  and  IS,  the 
agreements  will  be  aligned. 

Thus  subsequent  phases  of  these  agreements  will  incorporate  the 
relevant  standards  information  as  the  standards  become  available.  In 
general,  the  NMSIG  will  attempt  to  incorporate  information  from  a 
standard  that  has  progressed  to  the  DIS  or  IS  state  into  the 
subsequent  phases  of  the  implementors'  agreements. 

When  a defect  is  found  in  any  of  the  management  related  standards,  the 
reported  defect  may  be  technically  resolved  by  the  appropriate 
international  technical  committee  with  likely  approval  by  the  voting 
members  pending  for  several  months.  Since  relevant  defects  can't  be 
ignored  in  an  implementation,  these  agreements  will  note  defect 
resolutions  which  have  the  tentative  approval  of  the  appropriate 
standards  committee.  These  interim  resolutions  will  be  recorded  in 
section  18.4. 

Once  a defect  resolution  has  been  finalized  by  the  appropriate 
standards  body,  the  agreed  upon  resolution  will  be  incorporated  into 
the  next  phase  of  these  implementors  agreements.  If  appropriate,  a 
previous  phase  that  relied  on  an  interim  resolution  will  be  examined 
to  determine  whether  or  not  errata  should  be  issued  to  bring  the 
original  phase  into  line  with  the  final  resolution. 


18,2.2 Management  Architecture 

18.2.2.1  Systems  Management  Overview 

Editor's  Note;  This  section  is  tutorial. 

Reference  [SMO]  provides  an  overview  of  the  OSI  Systems 
Management  Architecture.  What  follows  is  a brief  summary  of 
the  information  contained  therein.  The  material  contained 
here  (i.e.  sec.  18.2.2.1)  is  tutorial  in  nature.  It  is  not 
intended  to  correct  deficiencies  that  may  exist  in  the 
standards  themselves.  This  information  is  primarily 
Intended  to  serve  as  an  aid  to  the  casual  reader  of  these 
requirements.  For  more  detail,  please  refer  to  the 
management  standards  referenced  below. 
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STANDARDS 

The  OSI  System  management  standards  are  grouped  as  follows: 

o References  [FRMWK]  and  [SMO]  address  the  general 
concepts . 

o References  [ALS] , [CMIS] , and  [CHIP]  address  the 
communications  standards. 

o References  [MIM] , [DMI],  [DMI] , and  [GDMO]  pertain 
to  the  definition  of  management  information 
(managed  objects). 

o References  [CMO] , [FMWD] , [SMWD] , [AMWD] , and 
[PMWD]  document  functional  area  standards. 

Editor's  Note:  Due  to  reorganization  of  doc’unents 
as  a result  of  the  Decembe'*'  1988 
SC21/WG4  meeting  in  Sydney, 
functions  have  been  separated  from 
the  management  functional  areas 
which  originally  developed  them. 
The  documents  which  describe  these 
functions  include  [OMF] , [SMF], 
[RMF],  [ARF] , and  [ERMF] . 


GENERAL  CONCEPTS 

Viewed  abstractly,  a communications  environment  is  made  up 
of  a collection  of  managed  objects.  Management  of  the 
communications  environment  is  viewed  as  being  an  information 
processing  application.  Management  activities  are  carried 
out  by  using  the  information  processing  application  to 
manipulate  and  monitor  the  managed  objects  that  make  up  the 
environment . 

Because  the  environment  being  managed  is  physically 
distributed,  the  components  of  the  information  processing 
application  are  themselves  distributed.  These  distributed 
components  take  the  form  of  management  application 
processes.  These  distributed  application  processes  may  be 
organized  in  many  ways,  as  for  example,  in  a hierarchical 
manner  or  on  a peer-to-peer  basis. 

Management  processes  are  divided  into  two  categories: 
managing  processes  and  agent  processes.  A managing  process 
is  that  part  of  a distributed  application  process  that  is 
responsible  for  carrying  out  one  or  more  management 
activities.  An  agent  process  is  responsible  for 
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manipulating  and  monitoring  an  associated  set  of  managed 
objects,  A managing  process  interacts  with  an  agent  process 
to  carry  out  the  management  activities  for  which  it  is 
responsible . 

An  agent  process  performs  the  management  function  upon 
receipt  of  a message  specifying  management  operations  on 
managed  objects.  Agent  processes  may  also  forward  messages 
to  managing  processes  to  convey  information  generated  by 
managed  obj  ects . 

APPLICATION  LAYER  COMMUNICATIONS 

A systems  management  application  entity  (SMAE)  is  that 
portion  of  a management  process  that  is  responsible  for 
communicating  with  other  management  processes  (or  more 
specifically,  other  SMAE's).  A SMAE  is  made  up  of  a 
collection  of  cooperating  application  service  elements 
(ASE's) . 

The  association  control  service  element  (ACSE)  is  used  to 
establish  associations  with  other  SMAE's.  Once  this  is 
done,  a systems  management  application  service  element 
(SMASE)  is  used  to  exchange  information  between  the 
associated  SlIAE's.  The  SMASE  realizes  the  abstract  notion 
of  messages  exchanged  between  management  processes. 

The  SMASE  relies  on  other  (standard)  ASE's  to  effect 
communications.  Notably,  the  services  of  the  common 
management  Information  service  element  (CMISE)  are  used. 

Taken  as  a whole,  a SMAE  ultimately  relies  on  presentation 
layer  services  to  communicate. 

FUNCTIONAL  AREAS 

Systems  manAgement  activities  are  grouped  into  five 
functional  areas  that  are  intended  to  capture  the  user 
requirements  imposed  on  management.  These  functional  areas 
are : 

o Configuration  Management 
o Fault  Management 

o Security  Management 

o Performance  Management 

o Accounting  Management 

Each  of  these  functional  areas  is  referred  to  as  a Specific 
Management  Functional  Area  (SMFA),  Each  SMFA  gives  rise  to 
a standard  that  identifies  the  following: 
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o A set  of  functions  that  support  the  functionality 
within  the  scope  of  the  SMFA. 

o The  procedures  associated  with  the  provision  of 
each  function. 


o The  services  required  to  support  these  procedures, 

o The  use  of  the  underlying  OSI  services  to  provide 

the  communications  needs . 

o The  classes  of  managed  objects  that  the  procedures 
will  operate  upon  in  order  to  provide  the 
functionality  defined  by  the  SMFA. 


18.2.2.2  Constraints /Assumptions  for  Phase  1 

The  focus  of  the  Phase  1 agreements  is  to  enable  a managing 
process  provided  by  one  vendor  to  interoperate  with  an  agent 
process  provided  by  a different  vendor  for  the  purpose  of 
performing  limited  management  on  a set  of  managed  objects. 
Specifically,  these  agreements  focus  on  the  managing 
process/agent  process  interface  and  the  techniques  used  to 
define  managed  objects.  These  agreements  do  not  address 
(nor  constrain)  the  mechanisms  used  by  agent  processes  to 
manipulate  managed  objects.  Nor  should  these  agreements 
inhibit  our  ability  to  provide  post-Phase  1 agreements  that 
meet  the  long  term  goals  associated  with  the  area  of  network 
management . 

In  order  to  accomplish  this  goal  in  a timely  fashion, 
several  simplifying  constraints  have  been  imposed  on  these 
agreements.  These  constraints  are  summarized  below. 

1.  These  agreements  support  only  a limited  set  of 
functionality.  Refer  to  sections  18.2.3  and  18.5 
for  a description  of  the  functionality  supported 
by  these  agreements. 

2.  No  agreements  are  provided  in  support  of  m.anaging 
process  to  managing  process  communications. 

3.  No  agreements  are  provided  regarding  management 
domains . 

4.  All  communications  supported  bj/  these  agreements 
rely  on  the  use  of  the  following  application 
service  elements:  the  association  control  service 
element  (ACSE) , the  common  management  information 
service  element  (CMISE) , Remote  Operations 
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Service  Element  (ROSE) , and  the  system  management 
application  service  element  (SMASE)  identified  in 
section  18.6. 

5.  All  communications  between  managing 
processes/agent  processes  are  based  on  connection- 
oriented  presentation  services. 

6.  These  agreements  do  not  rely  on  the  use  of 
Directory  Services. 

7.  No  agreements  regarding  the  security  of  management 
are  provided  except  for  the  use  of  access  control 
on  association  initialization. 

Editor's  Note:  The  NMSIG  has  requested,  via  a liaison 
statement,  that  the  Security  SIG  suggest 
appropriate  security  agreements  to 
address  this  area.  In  the  absence  of 
input  from  the  Security  SIG,  it  should 
be  noted  that  individual  management 
products  may  implement  proprietary 
security  policies  that  do  not  interfere 
with  interoperability.  For  example,  a 
given  managing  process  or  agent  process 
may  decide  to  refuse  an  A-Associate 
request  based  on  the  calling 
presentation  address  and  some  locally 
defined  criteria. 

8.  It  is  assumed  that  every  managed  object  instance 
will  be  associated  with  exactly  one  agent  process. 
This  agent  process  is  responsible  for  acting  as 
the  agent  for  the  managed  object  with  regard  to 
all  interactions  with  the  managing  systems. 

18.2.2.3  Migration  to  Future  Phases 

Editor's  Note:  This  section  will  document  the  migration 
plans  with  regard  to  ensuring  that  Phase  N 
products  can  interact  with  Phase  1 products. 


18.2.2.4  Relationship  to  Other  Management  Specifications 

Editor's  Note:  This  section  will  describe  the  degree  to 
which  implementations  that  conform  to  these 
agreements  will  interoperate  with 

implementations  that  conform  to  the  other 
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management  specifications  (including 

MAP/TOP) . 


18.2.3 Management  Scenarios 

Editor's  Note:  The  intent  of  this  section  is  to  amplify  the  high 
level  NM  requirements  to  be  met  by  these  lAs . In 
particular,  this  section  will  provide  a high  level 
view  of  the  functionality  supported  by  Phase  1 of 
these  agreements.  Based  on  these  scenarios,  one 
should  be  able  to  determine  the  scope  of  managed 
object  classes  that  are  required  to  satisfy  these 
scenarios , 


18.3  STATUS 


Section  18  is  currently  a working  draft  of  the  Phase  1 Network 
Management  Implementors  Agreements. 

Editor's  Note:  The  intention  is  to  possibly  move  at  least  some  of 
this  material  to  stability  in  1990.  Therefore, 
the  content  of  this  chapter  should  be  closely 
examined. 


18.4  ERRATA 


(None  as  yet) 


18.5  MANAGEMENT  FUNCTIONS  AND  SERVICES 


Editor's  Note:  The  text  in  this  section  (sec.  18.5)  is  currently 
undergoing  a major  revision,  to  be  completed  by  the 
June  1990  OIW.  Because  the  current  text  in  this 
section  will  be  replaced,  citations  in  this  section 
have  not  been  revised  to  reflect  the  current  updated 
references  in  section  18.1.1.  Consequently,  references 
cited  in  the  text  of  section  18.5  may  be  incorrect. 
However,  the  revised  text  of  this  section,  to  be 
completed  by  June  1990,  will  include  proper  reference 
citations . 

Editor's  Note:  To  aid  the  casual  reader,  parts  of  this  section  have 

been  written  in  a tutorial  fashion,  explaining  unclear 
or  obscure  areas  in  the  base  standards.  This  material 
will  be  deleted  when  transition  to  the  Stable 
Agreements  Document  occurs.  The  remaining  material 
contains  agreements  relative  to  the  base  standards  or 
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to  areas  deemed  important  for  interoperability  but  not 
contained  in  the  base  standards . 

Editor's  Note:  Tutorial  Material.  ISO  has  partitioned  network 
management  into  five  Specific  Management 
Functional  Areas  (SMFAs)  as  a convenience  for 
developing  requirements  particular  to 
configuration  management  (CM) , fault  management 
(FM) , performance  management  (PM) , security 
management  (SM),  and  accounting  management  (AM). 
These  requirements  are  specified  in  five  separate  SMFA 
standards  ([CMO],  [FMWD] , [SMWD] , [AMWD] , and  [PMWD]). 
Due  to  reorganization  of  documents  as  a result  of  the 
December  1988  SC21/WG4  meeting  in  Sydney,  functions 
have  been  separated  from  the  management  functional 
areas  which  originally  developed  them.  The  documents 
which  describe  these  functions  include  [OMF] , [SMF], 
[FUF] , [ERIRF],  [LCF] , and  [MSC] . 

Since  the  SMFAs  have  overlapping  requirements, 
management  functions  and  management  information 
applicable  to  one  SMFA  are  often  applicable  to 
other  SMFAs.  Therefore,  the  SMFAs  point  to 
separate  standards  that  contain  the  management 
functions  needed  to  satisfy  particular 
requirements . 

This  set  of  management  functions  is  referred  to  as  the 
System  Management  Functions  (SMFs) . They  provide  a 
generic  platform  of  common  network  management 
capabilities  available  to  any  management  application. 
For  example,  the  management  services  control  function 
[MSC]  may  be  used  to  report  events  to  satisfy  FM,  PM, 
AM,  and  SM  requirements.  The  log  control  function  [LCF] 
may  be  used  to  satisfy  both  FM  and  SM 
requirements . 

The  following  schematic  depicts  the  functional 
hierarchy  of  SMFs  and  SMFAs.  There  are  seven 
common  SMFs.  They  provide  much  of  the  network 
management  capabilities  needed  by  CM  and  FM.  When 
additional  requirements  are  identified  in  other 
SMFAs,  additional  SMFs  may  be  developed. 
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CMIS 


Lower  Layer  Services 


The  following  System  Management  Functions  are  undergoing 
standardization: 

(1)  Object  Management  Function  [OMF] 

(2)  State  Management  Function  [SMF] 

(3)  Relationship  Management  Function  [RMF] 
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(4)  Error  Reporting  and  Information  Retrieval  Function  [ERIRF] : 

a.  Error  Reporting  Service 

b.  Information  Retrieval  Service 

(5)  Management  Service  Control  Function  [MSC] : 

a.  Event  Control  Service 

b.  Service  Access  Control  Service 

(6)  Event  Log  Control  Function  [LCF] 

(7)  Confidence  and  Diagnostic  Test  Function  [FMWD] . 

For  the  NIST  NMSIG  Phase  1 network  management  agreements,  it  is 
agreed  that  only  the  first  six  functions  will  be  supported.  For 
each  supported  System  Management  Function  (secs,  18,5.1-18.5.6, 
below) , agreements  pertinent  to  the  accompanying  management 
communication  services  are  given. 


18.5.1  Obiect  Management  Function  Agreements 

Editor's  Note:  Tutorial  Material.  This  System  Management  Function 
provides  the  management  of  Objects  in  an  Open 
System  Environment.  In  this  environment,  a 
managed  object  (MO)  can  be  identified  as  an 
abstraction  of  a data  processing  resource  or  a 
data  communications  resource  that  can  be  remotely 
managed  through  the  use  of  OSI  management 
communication  Services  (sec.  18.6).  An  MO  may  be 
a physical  item  of  equipment,  a software 
component,  or  a combination  of  such.  Each  MO  has 
a set  of  management  information  associated  with  it 
and  an  MO  identifier  by  which  the  set  of 
management  information  can  be  manipulated  through 
the  use  of  the  OSI  management  communications 
services . 

The  NMSIG  Phase  1 network  management  agreements  support  all  the 
operations  and  services  in  the  object  management  standard  [OMF] , 
i.e.  , 

o Object  creation  operation 

o Object  deletion  operation 

o Object  renaming  operation 

o Attribute  reading  operation 

o Attribute  changing  operation 

o Object  listing  operation 
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o Enrol  Object  Service 

o Deenrol  Object  Service 

o Reenrol  Object  Service 

o Attribute  Change  Event  Report  Service 

o Add  Value  Event  Report  Service 

o Remove  Value  Event  Report  Service 


For  the  last  three  services  listed  above,  the  Event  Reporting 
Control  Model  (sec.  18.5.5)  applies. 


18.5.1.1  Object  Creation  Operation  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Object  Creation 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  create  an  instance  of  a 
managed  object  in  the  managed  system. 


The  following  agreements  and  clarifications  pertinent  to 
section  8.1  of  the  base  standard  [OMF]  and  regarding  the 
semantics  of  the  confirmed  CMIS  M- CREATE  service  (sec. 

8.3.4  in  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory,  except 
where  noted  below. 

CMIS  M-CREATE  request  parameters: 

<invokeIdentif ier> 

<managedObj  ectClass> 

<managedObjectInstance>  (1)  If  this  parameter  is  used 

in  the  request,  it  will 
identify  the 
distinguished 
name  of  the  object 
instance  to  be  created. 
The  distinguished  name  of 
a managed  object  instance 
is  created  by 
concatenating  in  sequence 
(ordered  list)  the 
relative  distinguished 
names  of  its  superiors  in 
the  containment  tree 
starting  at  the  root 
and  working  downward 
towards  the  managed 
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object  instance 
to  be  identified. 

(2)  Otherwise,  the  performing 
CMISE-service-user  will 
assign  a value  to  this 
identification  of  this 
instance . 

The  managed  object  definition  will  specify  whether  the 
manager  or  agent  will  provide  the  <managedObjectInstance> 
value.  This  means  that  for  a given  object  class  either  (1) 
must  always  be  used  or  (2)  must  always  be  used  (refer  to 
sec.  6. 1.5. 2.1  of  [MIM]) . 

<accessControl>  Refer  to  sections  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of 

this  chapter  for  agreements 
pertaining  to  this  parameter. 

<referenceObjectInstance>  When  this  parameter  is 

used  by  the  invoking 
CMISE-service-user,  it 
must  specify  an  existing 
object  instance  of  the 
same  class  as  the  object 
being  created. 

<attributeList>  This  parameter  must  provide  the 

attribute (s)  and  their  initial 
value (s)  for  the  object  instance  if 
they  are  neither  provided  as 
defaults  in  the  object  definition 
nor  obtained  from  the  reference 
object.  Otherwise,  a CMIS  error  of 
<invalidAttributeValue>  will  be 
returned  (sec.  8.3.4. 1.8  of 
[CMIS]) . 

Editor's  Note:  If  an  error  code  of  <missingAttributeValue> 
is  defined  in  the  standard  in  the  future,  it 
will  be  adopted  here. 

Editor's  Note;  The  standards  as  written  do  not  show  any  way 
(via  the  ATTRIBUTE  macro)  to  define  a 
default  value  for  an  attribute.  We  are 
assuming  that  it  is  possible  to  define  such 
default  values.  However,  it  is  not  required 
that  this  be  done  for  EVERY  attribute. 
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CMIS  M-CREATE  response  parameters: 

<invokeIdentif ier> 

<managedObj  ectClass> 

<managedObj ectlnstance>  Refer  to  section  18.6.3.2.8 

(Management  Communications)  of 
this  chapter  for  agreements 
pertaining  to  this  parameter. 

<attributeList>  This  parameter  specifies  all 

of  the  created  object 
attributes  and  values. 

Editor's  Note:  It  is 

anticipated 
that  section 
18.6  of  this 
chapter  will 
define  this  in 
common  for  all 
M-CREATE' s,  at 
which  time , the 
text  here  can 
refer  to  that 
section 
directly . 

<currentTime>  Refer  to  section  18.6.2.3  and 

18.6.3.1.3  (Management  Communications) 
of  this  chapter  for  agreements 
pertaining  to  this  parameter. 

Editor's  Note:  Can  any  manager  other 
than  the  manager 
that  created  the  object 
manage  this  new  object? 


Over  which  association(s) 
can  this  new  object  be 
managed? 


o 

the 

current 

association? 

o 

other 

extant 

associations? 
o new  associations? 
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This  issue  is  to  be 
determined  as  part  of  the 
general  association 
policy . 

Note  that  there  is  a more 
general  problem  which 
applies  to  access  rights 
and  ownership  of  the 
created  objects.  Maybe 
the  protocol  section 
should  set  the  policy  for 
the  CMIS  M- CREATE 
service? 


18.5.1.2  Object  Deletion  Operation  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Object  Deletion 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  delete  an  instance  of  a 
managed  object  in  the  managed  system. 

The  following  agreements  and  clarifications  pertinent  to 
section  8.3  of  the  base  standard  [OMF]  and  regarding  the 
semantics  of  the  confirmed  CMIS  M-DELETE  service  (sec. 

8.3.5  in  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory,  except 
where  noted  below. 

CMIS  M-DELETE  request  parameters: 

<invokeIdentif ier> 

<baseManagedObj ectClass>  (1)  If  scoping  is  used  for 

multiple  object 
selection,  this  parameter 
identifies  the  managed 
object  class  that  is 
to  be  used  as  the 
starting  point  for  the 
selection  of  managed 
objects  on  which  the 
filter  is  to  be  applied. 

(2)  If  scoping  is  used  to 
select  the  base  object 
only,  this  parameter 
identifies  the 
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class  of  the  object 
instance  to  be  deleted. 

Editor's  Note:  <n>  level  delete  is  to  be  discussed 
further . 


<baseManagedObjectInstance>  (1) 


(2) 


If  scoping  is  used 
for  multiple  object 
selection,  this 
parameter  identifies 
the  instance 
of  the  managed 
object  that  is  to  be 
used  as  the  starting 
point  for  the 
selection  of  managed 
objects  defined  by 
<scope>  on 
which  the  filter  is 
to  be  applied. 

When  a single  object 
is  targeted  for 
deletion  (i.e.  the 
scope  is  base 
managed  object 
alone) , this 
parameter  specifies 
the  managed  object 
instance  to  be 
deleted. 


Editor's  Note:  <n>  level  delete  is  to  be  discussed 
further . 


<accessControl> 


<synchronization> 

<scope> 


Refer  to  sections  18.6.2.4  and 
18.6.3.1.2  (Management 
Communications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 

<BestEffort>  is  required. 

This  parameter  defines  the  level(s) 
relative  to  the  base  managed  object 
from  which  objects  will  be  deleted. 
This  is  used  for  deleting  multiple 
object  instances.  It  will  be  set 
to  <baseObject>  if  single  object 
selection  is  used,  or  set  to  <n>  to 
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specify  the  depth  of  the  search,  or 
specify  the  whole  subtree. 

Editor's  Note:  <n>  level  delete  is  to  be  discussed 
further . 


<f ilter> 


CMIS  M-DELETE  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObj ectClass>  Refer  to  section  18.6 

<managed  Object  Instance>  (Management 

Communications)  of  this 
chapter  for  agreements 
pertaining  to  these 
parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 
18.6.3.1.3  (Management 
Communications)  of 
this  chapter  for  agreements 
pertaining  to  this  parameter. 

18.5.1.3  Object  Renaming  Operation  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Object  Renaming 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  rename  an  instance  of  a 
managed  object  in  the  managed  system. 

Editor's  Note:  This  section  is  very  controversial.  We  do 
not  feel  that  we  have  a clear  understanding 
of  what  an  OBJECT  NAME  is.  The  standard 
seems  to  imply  that  the  OBJECT  NAME  is  the 
distinguishing  attribute  defined  in  the 
object  definition.  If  this  is  so,  it  is  a 
<readonly>  attribute,  and  cannot  be  changed 
by  a CMIS  M-SET  service.  The  group  feels 
that  it  is  more  appropriate  to  use  a specific 
CMIS  M-ACTION  service  to  carry  out  this 
specific  operation.  The  group  will  submit 
comments,  in  this  regard,  to  ISO  by  the  March 
1989  ANSI  meeting. 
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The  following  section  aligns  with  the  current 
standard  and  may  change. 

Editor's  Note:  It  is  anticipated  that  this  service  will  have 
side  effects,  especially  with  regard  to 
associations  where  objects  existed  with  old 
names,  regarding  operations  with  the  objects 
under  old  names,  and  regarding  discriminator 
object  changes  at  the  managed  object's 
systems  as  well  as  the  destination  system. 

The  Object  Renaming  Operation  is  not  supported  in  the 
network  management  Phase  1 lAs . 


18.5.1.4  Attribute  Reading  Operation  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Attribute  Reading 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  return  the  specified 
attribute  values  for  an  instance  of  a managed 
object  in  the  managed  system. 

The  following  agreements  and  clarifications  pertinent  to 
section  8.8  of  the  base  standard  [OMF]  and  regarding  the 
semantics  of  the  confirmed  CMIS  M-GET  service  (sec.  8.3.1 
in  [CMIS])  are  supported  by  the  Phase  1 network  management 
lAs.  All  CMIS  parameters  are  mandatory,  except  where  noted 
below. 

CMIS  M-GET  request  parameters: 

<invokeIdentlf ier> 

<baseManagedObj  ectClass> 

<baseManagedObj  ectlnstance> 

<accessControl>  Refer  to  section  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 

<synchronization>  <bestEffort>  is  required. 

<scope> 

<f ilter> 
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<attributeIdList>  This  parameter  list  will 

contain  the  list  of  attributes 
to  be  retrieved.  If  the  list 
is  not  provided,  all 
attributes  will  be  retrieved. 


CMIS  M-GET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObj ectClass>  Refer  to  section  18.6 
<managedObj ectlnstance>  (Management  Communications)  of 

this  chapter  for  agreements 
pertaining  to  these 
parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 

18.6.3.1.3  (Management  Communications) 
of  this  chapter  for  agreements 
pertaining  to  this  parameter. 

<attributeList>  This  parameter,  provided  by 

the  managed  system,  returns 
the  list  of  ids  of  these  requested 
attributes  and  the  values  of  these 
attributes . 

If  an  error  occurs  in  the 
retrieval  process,  a CMIS 
ERROR  <GetListError>  will  be 
reported.  The  list  will 
include  all  requested  attributes, 
and  for  each  attribute  there  will 
be  chosen  either  the  attribute 
value  (choice  of  Tag  [1])  for  the 
successful  retrieval  of  an 
attribute,  or  an  attributeldError 
(choice  of  Tag  [0])  for  the  failure 
case.  Refer  to  section  8.3.1.1.14 
in  [CMIS]  for  more  information. 


18.5.1.5  Attribute  Changing  Operation  Agreements: 
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Editor’s  Note:  Tutorial  Material.  The  Attribute  Changing 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  change  the  values  of  one 
or  more  specified  attributes  for  a managed 
object  instance  in  the  managed  system. 


The  following  agreements  and  clarifications  pertinent  to 
section  3.9  of  the  base  standard  [OMF]  and  regarding  the 
semantics  of  the  confirmed  CMIS  M-SET  service  (sec.  8.3.2 
in  [CMIS])  are  supported  by  the  Phase  1 network  management 
lAs . All  CMIS  parameters  are  mandatory,  except  where  noted 
below. 


CMIS  M-SET  request  parameters: 

< Invoke Identifier> 

<mode>  This  parameter  will  be  set  to 

' confirmed' . 


<baseManagedObj  ectClass> 


<baseManagedObjectInstance> 


<accessControl>  Refer  to  sections  18.6.2.4  and 

18.6.3.1.2  (Management  Communica- 
tions) of  this  chapter  for 
agreements  pertaining  to  this 
parameter. 

<synchronization>  <bestEffort>  is  required, 

<scope> 

<f ilter> 


<attributeList>  This  parameter  will  contain  the 

list  of  attributes  whose  values  are 
to  be  modified  and  the  desired  new 
values . 


CMIS  M-SET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObj ectClass>  Refer  to  section  18.6 
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<ffianagedObj ectlnstance>  (Management  Communications)  of 

this  chapter  for  agreements 
pertaining  to  these 
parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 

18.6.3.1.3  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 

<attributeList>  This  parameter,  provided  by 

the  managed  system,  returns 
the  list  of  attribute  ids  of 
the  modified  attributes  and 
their  modified  values. 

If  an  error  occurs  in  the 
process,  a CMIS  ERROR 
<SetListError>  will  be  reported. 

The  list  will  include  all 
attributes  requested  for 
modification,  and  for  each  one, 
choose  either  an  <attribute> 

(choice  of  Tag  [1])  for  the 
successful  modification  of  an 
attribute,  or  an  <attributeError> 
(choice  of  Tag  [0])  for  the  failure 
case.  Refer  to  (sec.  8.3.2.1.14  in 
[CMIS])  for  more  Information. 


18.5.1.6  Object  Listing  Operation  Agreements: 

Editor's  Mote;  Tutorial  Material.  The  Object  Listing 

operation  is  used  by  a managing  system  to  ask 
a managed  system  to  retrieve  the  names  of  a 
defined  set  of  managed  objects  in  the  managed 
system.  Other  attributes  can  also  be 
retrieved  by  specifying  the  attribute  names 
in  the  request. 

The  following  agreements  and  clarifications  pertinent  to 
section  8.7  of  the  base  standard  [OMF]  and  regarding  the 
semantics  of  the  confirmed  CMIS  M-GET  service  (sec.  8.3.1 
in  [CMIS])  are  supported  by  the  Phase  1 network  management 
lAs.  All  CMIS  parameters  are  mandatory,  except  where  noted 
below. 
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Editor's  Note:  This  section  is  controversial  because  we  must 
again  work  with  the  problematic  definition  of 
an  OBJECT  NAME.  Comments  will  be  submitted 
to  the  ANSI  meeting  in  March  1989. 

The  following  section  assumes  that  the  OBJECT  NAME  is  the 
same  as  the  <Name>  attribute  which  represents  the 
distinguished  Name. 


CMIS  M-GET  request  parameters: 
<invokeIdentif ier> 
<baseManagedObj  ectClass> 
<baseManagedObj  ectlnstance> 


<accessControl> 


<synchronization> 
<scope> 

<f ilter> 

<attributeIdList>  (1) 

(2) 


Refer  to  section  18.6.2.4  and 
18.6.3,1.2  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to  this 
parameter . 

<bestEffort>  is  required. 


If  this  parameter  is  used, 
the  list  will  include  at  least 
the  <Name>  attribute. 

If  the  list  is  not  provided, 
all  attributes  including  the 
<Name>  attribute  will  be 
retrieved. 


CMIS  M-GET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObj ectClass>  Refer  to  section  18,6 
<managed0bjectlnstance>  (Management  Communications)  of 

this  chapter  for  agreements 
pertaining  to  these 
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parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 
18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to 
this  parameter. 

<attributeList>  This  parameter,  provided  by 

the  managed  system,  returns 
the  attribute  ids  and  values 
for  the  specified  attributes 
(including  the  object  name(s) 
of  the  requested  managed 
object's  <Name>  attribute). 

If  an  error  occurs  in  the 
retrieval  process,  a CMIS 
ERROR  <GetListError>  will  be 
reported.  (sec.  8.3.1.1.14  in 
[CMIS] ) 


18.5.1.7  Object  Management  Services  Agreements 

Editor's  Note:  Tutorial  Material.  Each  of  the  Object 

Management  Services  uses  an  unconfirmed  M- 
EVENT-REPORT  CMIS  service  (sec.  8.3.1  in 
[CMIS])  to  convey  its  information. 

The  Event  Reporting  Model  (see  sec.  18.5.5  in  this 
chapter  and  [ERIRF] , [MSC] , [DSO])  defines  the  following 
procedure:  The  agent  receives  notifications  from  the 
appropriate  managed  objects  and  causes  these  potential  event 
reports  to  be  checked  against  all  Event  Forwarding 
Discriminators.  The  result  of  this  sieve  process  v/ill  yield 
zero,  one  or  more  event  reports  to  be  transmitted  to  the 
destination  systems  (according  to  the  attributes  of  the 
relevant  discriminators)  according  to  the  services  defined 
in  the  subsequent  sub- sections . One  discriminator  may  cause 
the  sending  of  multiple  event  reports,  if  the  multi-valued 
attribute  ManagementUserldentif ication  contains  multiple 
AEtitles.  Additionally,  multiple  discriminators  may  filter 
the  same  potential  event  reports  and  hence  generate  multiple 
event  reports . 

Editor's  Note:  Some  of  the  text  in  this  paragraph  should  be 
moved  to  the  discussion  of  the  Event 
Reporting  Model  in  18.5.4,  while  retaining 
some  here. 
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The  following  agreements  and  clarifications  pertinent  to 
sections  8.2,  8,4,  8.6,  8.10,  8.11,  and  8.12  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS  M- 
EVENT-REPORT  parameters  are  supported  by  the  Phase  1 network 
management  agreements  for  all  the  Object  Management  Services 
sections  8. 5. 1.7.1  through  8. 5. 1.7. 6,  below: 

<invokeIdentif ier> 


<mode> 


This  parameter  is  set  to 
<unconf irmed> . 


<managedObj  ectClass> 
<managedObj  ectlnstance> 


Refer  to  section  18.6 
(Management  Communications)  of 
this  chapter  for  agreements 
pertaining  to  these 
parameters , 


18.5.1.7.1 Enrol  Object  Service  Agreements 

Editor's  Note:  Tutorial  Material.  The  Enrol  Object 

Service  is  used  by  the  managed  system  to 
report  a creation  event  of  a new  managed 
object  instance  to  a managing  system. 

In  addition  to  the  agreements  and  clarifications  in 
section  18.5.1.7,  the  following  agreements  and 
clarifications  pertinent  to  section  8,2  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS 
M- EVENT-REPORT  parameters  are  supported  by  the  Phase  1 
network  management  agreements: 

CMIS  M- EVENT -REPORT  request  parameters: 

<eventType>  This  parameter  identifies  the 

<enrolObj ect>  Event  whose  object 
identifier  is  defined  in  [OMF] . 

<eventTime>  This  parameter  specifies  the 

time  when  the  new  instance  was 
created.  Refer  to  sections 
18.6.2.3  and  18.6.3.1.3  (Management 
Communications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 
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<eventArguinent>  This  parameter  is  not  used  for 

this  service . 


18.5.1.7.2 Deenrol  Object  Service  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Deenrol  Object 
Service  is  used  by  the  managed  system 
to  report  the  deletion  of  a managed 
object  instance  to  a managing  system. 

In  addition  to  the  agreements  and  clarifications  in 
section  18.5.1,7,  the  following  agreements  and 
clarifications  pertinent  to  section  8.4  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS 
M- EVENT -REPORT  parameters  are  supported  by  the  Phase  1 
network  management  agreements: 


<eventType>  This  parameter  identifies  the 

<deenrolObj ect>  Event  whose  object 
identifier  is  defined  in  [OMF] . 

<eventTime>  This  parameter  specifies  the  time 
when  the  object  instance  was 
deleted.  Refer  to  sections 
18.6.2.3  and  18.6.3.1.3  (Management 
Communications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 

<eventArgument>  This  parameter  is  not  used  for 

this  service. 


18.5.1.7.3 Reenrol  Object  Service  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Reenrol  Object 
Service  is  used  by  the  managed  system 
to  report  the  renaming  of  a managed 
object  instance  to  a managing  system. 

The  Reenrol  Object  Sevice  is  not  supported  in  the 
network  management  Phase  1 lAs . 
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18.5.1.7.4  Attribute  Change  Event  Report  Service 

Agreements : 

Editor's  Note:  Tutorial  Material.  The  Attribute  Change 
Event  Report  Service  is  used  by  the 
managed  system  to  report  an  attribute 
change  event  to  the  managing  system.  The 
attribute  change  event  indicates  a 
change  in  the  value (s)  of  one  or  more 
attributes  of  a managed  object. 

In  addition  to  the  agreements  and  clarifications  in 
section  18.5.1.7,  the  following  agreements  and 
clarifications  pertinent  to  section  8.10  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS 
M- EVENT -REPORT  parameters  are  supported  by  the  Phase  1 
network  management  agreements: 

<eventType>  This  parameter  identifies  the 
<attributeChange>  Event  whose 
object  identifier  is  defined 
in  [OMF] . 

<eventTime>  This  parameter  specifies  the 
time  when  the  attribute  value 
was  changed  in  the  object 
instance.  Refer  to  sections 
18.6.2.3  and  18.6.3.1.3 
(Management  Communications)  of 
this  chapter  for  agreements 
pertaining  to  this  parameter. 

<eventArgument>  This  parameter  will  contain 

the  tuple  <attributeld, 
oldAttributeValue , 
newAttributeValue>  (sec.  9 in 
[OMF]).  The  oldAttributeValue 
must  be  presented. 

18.5.1.7.5 Add  Value  Event  Report  Service 

Agreements : 


Editor's  Note:  Tutorial  Material.  The  Add  Value  Event 
Report  Service  is  used  by  the  managed 
system  to  report  the  addition  of  a value 
to  a multi-valued  attribute  of  a managed 
object  at  an  open  system. 

In  addition  to  the  agreements  and  clarifications  in 
section  18.5.1.7,  the  following  agreements  and 
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clarifications  pertinent  to  section  8.11  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS 
M- EVENT -REPORT  parameters  are  supported  by  the  Phase  1 
network  management  agreements : 


<eventType>  This  parameter  identifies  the 

<addValue>  Event  whose  object 
identifier  is  defined  in 
[OMF] . 

<eventTime>  This  parameter  specifies  the 

time  when  the  new  attribute  value 
was  added  to  the  object  instance. 
Refer  to  sections  18.6.2.3  and 
18.6.3.1.3  (Management 
Conununications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 


<eventArgument>  This  parameter  will  contain 

the  tuple  <attributeld, 
newAttributeValue>,  where 
<newAttributeValue>  is  the 
attribute  value  just  added, 
(sec.  9 of  [OMF]). 


18.5.1.7.6 Remove  Value  Event  Report  Service 

Agreements : 

Editor's  Note:  Tutorial  Material.  The  Remove  Value 
Event  Report  Service  is  used  by  the 
managed  system  to  report  the  removal  of 
a value  from  a multi-valued  attribute  of 
a managed  object  at  an  open  system. 

In  addition  to  the  agreements  and  clarifications  in 
section  18.5.1.7,  the  following  agreements  and 
clarifications  pertinent  to  section  8.12  of  the  base 
standard  [OMF]  and  regarding  the  semantics  of  the  CMIS 
M- EVENT -REPORT  parameters  are  supported  by  the  Phase  1 
network  management  agreements: 


<eventType>  This  parameter  identifies  the 
<removeValue>  Event  whose 
object  identifier  is  defined 
in  [OMF] . 
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<eventTi5iie>  This  parameter  specifies  the 
time  when  the  attribute  value 
was  deleted  from  the  object 
instance.  Refer  to  sections 
18.6.2.3  and  18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to 
this  parameter. 

<eventArgi.iment>  This  parameter  will  contain 

the  tuple  <attributeld, 
oldAttributeValue>,  where 
<oldAttributeValue>  is  the 
attribute  value  just  deleted, 
(sec . 9 of  [OMF] ) . 


18.5.2  State  Management  Function  Agreements 

Editor's  Note:  Tutorial  Material.  The  State  Management  Function 
provides  for  the  examination,  setting  and 
notification  of  changes  in  the  management  state  of 
existing  managed  objects.  The  managed  state  of  a 
managed  object  represents  its  instantaneous 
condition  of  availability  and  operability  from,  the 
point  of  view  of  configuration  management.  The 
managed  state  consists  of  (1)  operational  state, 
and  (2)  administrative  state. 

A list  of  the  possible  combinations  of  the 
operational  and  administrative  states  is  given  in 
(table  1,  sec.  7.2,  [SMF]).  The  purpose  of  this 

list  is  to  control  the  availability  of  a managed 
object,  and  to  make  visible  information  about  the 
general  availability  of  a managed  object. 

The  Phase  1 network  management  agreements  support  the  two 
operations  and  one  service  defined  in  the  base  standard  (sec.  8 
of  [SMF] ) , i.e. , 

o State  reading  operation 
o State  changing  operation 
o State  change  reporting  service. 

For  the  State  change  reporting  Service,  the  Event  Reporting 
Control  Model  (sec.  18.5.5.1.1)  applies. 


18.5.2.1  State  Reading  Operation  Agreements: 
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Editor’s  Note:  Tutorial  Material.  The  state  reading 

operation  enables  the  managing  system  to 
request  the  managed  system  to  return  the 
values  of  the  configuration  state  attributes 
which  include  the  operational  and/or 
administrative  state (s)  of  one  or  more 
instances  of  managed  object(s). 

The  following  agreements  and  clarifications  pertinent  to 
section  8.1  of  the  base  standard  [SMF]  and  regarding  the 
semantics  of  CMIS  M-GET  service  (sec.  8.3.1  in  [CMIS]) 
are  supported  by  the  Phase  1 network  management  lAs . All 
CMIS  parameters  are  mandatory,  except  where  noted  below. 

CMIS  M-GET  request  parameters: 

<i nvoke I dent i f ie r> 


<baseManagedObj  ectClass> 
<baseManagedObj  ectlnstance> 


<accessControl> 


<synchronization> 

<scope> 

<filter> 


Refer  to  sections  18.6.2.4  and 
18.6.3.1.2  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to 
this  parameter. 

<bestEffort>  is  required. 


<attributeIdList>  This  parameter  list  will 

include  the  list  of  state 
attribute (s)  (<operational 
state>,  <administrative 
state>)  which  the  managing 
system  would  like  to  obtain. 
If  the  list  is  not  provided, 
all  attributes  including  the 
state  attributes  will  be 
retrieved. 

CMIS  M-GET  response  parameters: 

<invokeIdentif ier> 

<linkedldentifier> 

<managedObj ectClass>  Refer  to  section  18,6 
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<managedObjectInstance>  (Management  Communications)  of 

this  chapter  for  agreements 
pertaining  to  these 
parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 

18.6.3.1.3  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 

<attributeList>  This  parameter,  provided  by 

the  managed  system,  returns 
the  list  of  requested  state 
attributes  and  their  values. 

If  an  error  occurs  in  the 
retrieval  process,  a CMIS 
ERROR  <GetLlstError>  will  be 
reported.  (sec.  8.3.1.1.14  in 

[CMIS]) 


18.5.2.2  State  Changing  Operation  Agreements: 

Editor's  Note:  Tutorial  Material.  The  state  changing 

operation  enables  the  managing  system  to 
request  the  managed  system  to  change  the 
value  of  the  administrative  state  attribute 
of  one  or  more  instances  of  a managed 
obj  ect (s) . 

The  following  agreements  and  clarifications  pertinent  to 
section  8.2  of  the  base  standard  [SMF]  and  regarding  the 
semantics  of  CMIS  M-SET  service  (sec.  8.3.2  in  [CMIS]) 
are  supported  by  the  Phase  1 network  management  lAs.  All 
CMIS  parameters  are  mandatory,  except  where  noted  below. 

CMIS  M-SET  request  parameters: 

<lnvokeIdentif ier> 

<mode>  'Confirmed'  is  to  be  used. 

<baseManagedObjectClass> 

<baseManagedObj  ectlnstance> 

<accessControl>  Refer  to  section  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of  this  chapter 
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for  agreements  pertaining  to 
this  parameter. 

<synchronization>  <bestEffort>  is  required. 
<scope> 

<f ilter> 

<attributeList>  This  parameter  will  include 

the  state  attribute 
(<administrativeState>) 
and  its  desired  new  value. 


CMIS  M-SET  response  parameters: 

<invokeIdentif ier> 

<linkedldentifier> 

<managedObjectClass>  Refer  to  section  18.6 
<managedObj ectlnstance>  (Management  Communications)  of 

this  chapter  for  agreements 
pertaining  to  these 
parameters . 

<currentTime>  Refer  to  sections  18.6.2.3  and 

18.6.3.1.3  (Management  Communications) 
of  this  chapter  for  agreements 
pertaining  to  this  parameter. 

<attributeList>  This  parameter,  provided  by 

the  managed  system,  returns 
the  attribute  ids  and  values 
for  the  specified  attributes 
(including  the  modified  state 
attribute) . 

If  an  error  occurs  in  the 
process,  a CMIS  ERROR 
<SetListError>  will  be 
reported.  (sec.  8.3.2.1.14 
in  [CMIS]) 


18.5.2.3  State  Change  Reporting  Service  Agreements: 

Editor's  Note:  Tutorial  Material.  The  state  change 

reporting  service  enables  the  managed  system 
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to  report  the  change  of  a state  attribute 
(i.e.  either  the  operational  state  or 
administrative  state)  of  a managed  object  to 
a managing  system. 

The  following  agreements  and  clarifications  pertinent  to 
section  8.3  of  the  base  standard  [SMF]  and  regarding  the 
semantics  of  CMIS  M- EVENT -REPORT  service  (sec.  8.2.1  in 
[CMIS])  are  supported  by  the  Phase  1 network  management  lAs . 
All  CMIS  parameters  are  mandatory,  except  where  noted  below. 

<invokeIdentifier> 


<mode> 


This  parameter  is  set  to 
<unconf irmed>. 


<managedObj  ectClass> 
<managedObj  ectlnstance> 


Refer  to  section  18.6 
(Management  Communications)  of 
this  chapter  for  agreements 
pertaining  to  these 
parameters . 


<eventType> 


This  parameter  identifies  the 
<stateChange>  Event  whose 
object  identifier  is  defined 
in  [DMA] . 


<eventTime> 


This  parameter  specifies  the 
time  when  the  object  instance 
state  attribute  value  was 
changed.  Refer  to  sections 
18.6.2.3  and  18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to 
this  parameter. 


<eventArgument> 


This  parameter  will  contain 
the  tuple  <oldConf igurationState , 
newConf igurationState>  for  the 
newly  changed  state  object 
instance  [DMA] . 


18.5.3 Relationship  Management  Function 

Editor's  Note:  Tutorial  material.  A relationship  is  a set  of 
rules  that  describe  how  the  operation  of  one  part 
of  an  open  system  affects  the  operation  of  another 
part  of  an  open  system.  The  operation  of  a 
managed  object  may  affect  its  related  managed 


18-42 


March  1990  (Working) 


object  directly  or  indirectly.  A direct 
relationship  exists  between  two  managed  objects 
when  some  portion  of  the  management  information 
associated  with  one  managed  object  expressly 
identifies  the  other  managed  object  with  which  it 
has  a relationship.  Indirect  relationship 
information  can  be  deduced  from  the  concatenation 
of  two  or  more  direct  relationships. 

In  order  to  manage  the  relationship  information  of 
two  directly  related  managed  objects,  a 
relationship  can  be  modelled  as  a third  object,  or 
a pair  of  bound  attributes,  one  for  each  of  the 
related  managed  objects.  The  latter  approach  is 
the  one  currently  taken  by  the  ISO  OS I management 
standard  [RMF] . The  relationship  is  presented  by 
explicitly  including,  as  one  of  a set  of  values  of 
each  bound  attribute  of  the  pair,  the  name  of  the 
other  managed  object  to  which  it  is  related.  This 
binding  is  called  an  explicit  relationship. 
Therefore,  an  explicit  relationship  between  a pair 
of  managed  objects  can  be  represented  by  a pair  of 
conjugate  values  of  the  bound  relationship 
attributes  of  the  two  managed  objects. 

At  any  given  time,  within  an  open  systems 
environment,  one  managed  object  may  be  a part  of 
several  different  types  of  relationships.  For 
each  type  of  relationship,  depending  on  the  roles 
of  the  managed  objects  (i.e.  the  set  of  rules 
governing  the  interactions  between  the  two  related 
managed  objects),  the  relationship  can  be 
symmetric  or  asymmetric.  If  the  roles  of  the  two 
managed  objects  are  the  same,  then  the 
relationship  (role)  is  symmetric,  otherwise  it  is 
asymmetric.  For  every  possible  relationship  role 
of  a managed  object,  there  exists  a corresponding 
relationship  attribute.  Hence,  in  order  to 
describe  a symmetric  relationship,  two  bound 
attributes  of  the  same  role -type  of  relationship 
attributes  are  needed.  To  describe  an  asymmetric 
relationship,  two  role- types  of  bound  relationship 
attributes  are  needed.  The  name  of  a relationship 
attribute  of  a managed  object  implies  the 
relationship  role  of  the  related  managed  objects 
and  the  type  of  the  explicit  relationship.  The 
value  of  a relationship  attribute  for  a managed 
object  may  be  multi-valued  or  "null."  These 
values  are  the  names  of  the  associated  managed 
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objects  having  the  same  type  of  explicit 
relationship  with  the  managed  object. 

The  types  of  explicit  relationships  defined  in  the 
standards  [RMF]  are:  1)  Service  relationship  which 
can  be  described  by  relationship  attributes  of  the 
Service  Provider  and  the  Service  User;  2)  Peer 
relationship  which  is  a symmetric  relationship  and 
is  described  by  the  Peer  attribute  type;  3)  Backup 
relationship  which  can  be  described  by 
relationship  attributes  of  the  "Primary"  operation 
object  and  the  "Secondary"  backup  object;  and  4) 
Group  relationship  which  can  be  described  by 
relationship  attributes  of  "Member"  and  "Owner". 

The  collection  of  all  relationship  attributes  of 
one  managed  object  can  be  named  under  a group 
attribute.  If  defined,  this  named  group  attribute 
will  be  an  attribute  of  all  of  the  managed  object 
classes . 

Between  two  managed  objects  there  may  exist 
containment  relationships  in  addition  to  the 
explicit  relationships.  A containment 
relationship  is  automatically  created  when  the 
containing/contained  managed  objects  are  created. 
A containment  relationship  is  implicitl}'’  reflected 
in  the  name  (i.e.  a sequence  of  AVAs)  of  the 
contained  managed  object.  Managed  object  naming 
is  part  of  SMI  and  is  specified  during  the  managed 
object  definition.  Therefore,  no  relationship 
management  service  is  required  to  manage 
containment  relationship  information. 

The  Relationship  Management  Function  specified  by 
[RMF]  provides  the  following  services  to  add, 
remove,  change  and  display  the  relationship 
attribute  information  for  managed  objects,  and  to 
report  events  of  relationship  activities. 

Relationship  Creation  is  a service  which  allows 
the  managing  process  (or  the  invoker)  to  request 
the  managed  process  (or  the  performer)  to  add  a 
value  to  the  specified  relationship  attribute  of 
the  specified  managed  objects  in  order  to  reflect 
a newly  created  (or  to  be  created)  relationship. 

Relationship  Deletion  is  a service  which  allows 
the  invoker  to  request  the  performer  to  remove  the 
value(s)  from  the  set  of  its  relationship 
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attributes  of  specified  managed  objects  in  order 
to  reflect  a newly  removed  (or  to  be  removed) 
relationship . 

Relationship  Changing  is  a service  which  allows 
the  invoker  to  request  the  performer  to  replace 
one  or  more  value(s)  of  the  specified  relationship 
attributes  of  the  specified  managed  objects. 

Relationship  Listing  is  a service  which  allows  the 
invoker  to  request  the  performer  to  return  the 
value(s)  of  the  specified  relationship 
attribute (s)  of  the  specified  / selected  managed 
obj  ect . 

Related  Object  Listing  is  a service  which  allows 
the  invoker  to  request  the  performer  to  return  the 
name(s)  and  the  other  specified  attribute (s)  and 
value (s)  of  the  selected  managed  objects  which 
have  the  specified  relationship  attribute(s) 
value (s)  which  match  successfully  to  the  target 
managed  object. 

Relationship  Creation  Reporting  is  a service  which 
allows  a managed  process  to  report  the 
relationship  creation  event  to  the  managing 
process (es)  (not  necessarily  the  original  managing 
process)  . 

Relationship  Deletion  Reporting  is  a service  which 
allows  the  managed  process  to  report  the 
relationship  deletion  event  to  the  other 
process (es)  (not  necessarily  the  original  managing 
process) . 

Relationship  Change  Reporting  is  a service  which 
allows  the  managed  process  to  report  the 
Relationship  Change  Event  to  the  managing  process 
(not  necessarily  the  original  managing  process) . 

Since  a relationship  is  represented  by  a pair  of 
bound  relationship  attributes,  in  order  to  keep 
the  integrity  of  relationship  management 
information,  it  takes  at  least  two  services  to 
complete  a transaction.  The  transaction 
processing  and  the  commitment  control  are  outside 
the  scope  of  this  section. 

Editor's  Note:  The  following  sections  are  to  be  agreed  upon. 
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18.5.3.1  Relationship  Creation  Service  Agreements 

Editor's  Note:  This  service  is  mapped  to  M-SET  CMIS 
Services.  It  is  assumed  that  the  CMIS 
Add/Remove  of  attribute  value  function  is 
supported  in  Phase  1 here. 


CMIS  M-SET  Request  parameters  clarifications: 

<invokeIdentif ier> 

<mode> 

<baseManagedObj  ectClass> 

<baseManagedObj  ectlnstance> 

<accessControl> 

<synchroni2ation> 

<scqpe>  <Base  object  only>  is  to  be  used. 

<f ilter> 

<modif icationList>  Tliis  parameter  specifies  a set  of 

(at  least  one)  tuples:  <a  specified 
Relationship  Attribute  of  the 
selected  Managed  Object,  to-be- 
added  relationship  attribute  value, 
add-value  operation>  for  the 
relationship  to  be  created. 

CMIS  M-SET  Response  parameters  clarifications: 

<invoke I dent i f ie  r> 

<linkldentif ier>  This  parameter  shall  not  be 

returned. 

cManagedObj ectClass>  Refer  to  section  18.6. 

<ManagedObj  ectlnstance> 

<attributeList>  This  parameter  specifies  a set  of 

<Relationship  Attribute  of  the 
selected  managed  object,  the  value 
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that  was  added>  for  the  relation- 
ship created. 

<currentTime>  Refer  to  section  18.6. 


18.5.3.2  Relationshio  Deletion  Service  Agreements 

This  Service  shall  use  the  M-SET  CMIS  service  to  carry  its 
information  with  the  following  clarification: 

CMIS  M-SET  request  parameters: 

<invokeIdentifier> 

<mode> 

<baseManagedObj ectClass>  This  parameter  specifies  the 

base  of  the  Class  of  the 
managed  objects  with  whose 
instance  a relationship  with 
another  managed  object  is  to 
be  deleted. 

<baseManagedObj ectlnstance>  This  parameter  specifies 

the  instance  of  the  base 
of  managed  object  with 
whom  a relationship  with 
another  managed  object  is 
to  be  deleted. 

<accessControl> 

<synchronization> 

<scope> 

<f ilter> 

<modif icationList>  This  parameter  specifies  a set  of 

<specified  Relationship  Attribute 
name, its  value  to  be  removed, 
remove -value  operation>. 

CMIS  M-SET  Response  parameters: 

< invoke I den t i f i e r> 

< 1 ink  I de  xi  t i f i e r > 
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<ManagedObjectClass>  Refer  to  section  18.6. 

<ManagedObj  ectlnstance> 

<attributeList>  This  parameter  specifies  a set  of 

<specified  Relationship  Attribute 
of  the  Managed  Object,  the  value 
that  is  removed>. 

<currentTime>  Refer  to  section  18.6. 

18.5.3.3  Relationship  Change  Service  Agreements 

This  Service  shall  use  M-SET  GMIS  service  to  carry  its 
information  with  the  following  clarification: 

GMIS  M-SET  request  parameters: 

<invokeIdentif ier> 

<mode> 

<baseManagedObj ectGlass>  This  parameter  specifies  the 

base  of  the  Glass  of  the 
managed  objects  with  whose 
instance  a relationship  with 
another  Managed  Object  is  to 
be  changed. 

<baseManagedObj ectlnstance>  This  parameter  specifies 

the  instance  of  the  base 
managed  object  with  whom 
a relationship  with 
another  managed  object  is 
to  be  changed. 

<accessGontrol> 

<synchronization> 

<scope>  <base  object  only> 

<f ilter> 

<modif icationList>  This  parameter  specifies  a set  of 

<specified  Relationship  Attribute 
of  the  selected  managed  object,  the 
old  value  to  be  replaced,  the  iiew 
value,  replace  operation>. 
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Editor's  Note:  This  has  to  be  verified,  i.e.,  whether 
the  CMIS  DAD2  supports  this  old  and  new 
value  syntax.  If  this  is  the  case,  we 
have  to  replace  the  whole  set-value  of 
the  attribute. 

CMIS  M-SET  Response  parameters: 

< invoke I dent i f ie  r> 

<linkldentif ier>  This  parameter  shall  not  be 

returned. 

<ManagedObj ectClass>  Refer  to  section  18.6. 

<ManagedObj  ectlnstance> 

<attributeIdList>  This  parameter  specifies  a set  of 

<specified  Relationship  Attribute 
of  the  selected  managed  object,  its 
new  value>. 

<currentTime>  Refer  to  section  18.6. 


18.5.3.4  Relationship  Listing  Service  Agreements 

This  Service  shall  use  M-GET  CMIS  service  to  carry  its 
information  with  the  following  clarification: 

CMIS  M-GET  request  parameters: 

<invokeIdentif ier> 

<baseManagedObj ectClass>  This  parameter  specifies  the 

base  of  the  managed  object 
class  with  which  instances, 
the  value (s)  of  their 
specified  relationship 
attributes,  are  to  be  listed. 

<baseMan.agedObj ectlnstance>  This  parameter  specifies 

the  instance  of  the 
manage  d ob j e c t s . 


<accessContrcl> 

<synchronization> 


<scope> 
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<f ilter> 

<AttributeIdList>  This  parameter  specifies  the  list 

of  relationship  attributes  with 
their  relationship  value (s)  which 
is (are)  to  be  returned. 

CMIS  M-GET  Response  parameters: 

<invokeIdentif ier> 

<linkldentif ier> 

<ManagedObj ectClass>  Refer  to  section  18.6. 

<ManagedObj  ectlnstance> 

<attributeList>  This  parameter  returns  a set  of 

<relationship  attribute  id, 
attribute  value (s)>. 

<currentTime>  Refer  to  section  18.6. 


18.5.3.5  Related  Object  Listing  Service  Agreements: 

This  Service  shall  use  M-GET  CMIS  service  to  carry  its 
information  with  the  following  clarification: 

CMIS  M-GET  request  parameters: 

<invokeIdentif ier> 

<baseManagedObj ectClass>  This  parameter  specifies  the 

Class  of  the  base  managed 
object  from  which  the  related 
object  instances  are  to  be 
selected  for  filtering. 

<baseManagedObj ectlnstance>  This  parameter  specifies 

the  instance  of  the  base 
Managed  Object  from  which 
the  related  object 
instances  are  to  be 
selected  for  filtering. 


<accessControl> 

<synchronization> 
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<scope>  All  3 options  are  allowed  and  supported. 

<filter>  The  filter  should  specify  the  relationship 
attribute  name  and  its  value  to  be  matched 
(i.e.  the  name  of  the  target  object  to  which 
the  selected  objects  are  related) . 

<AttributeIdList>  Refer  to  section  18.6. 

CMIS  M-GET  Response  parameters: 

< Invoke Identifier> 

<linkldentif ier> 

<ManagedObj ectClass>  Refer  to  section  18.6. 
<ManagedObj  ectlnstance> 

<attributeList>  This  parameter  returns  a set  of 

<the  name  of  the  related  object, 
the  value (s)  of  the  requested 
attribute(s)>. 

<currentTime>  Refer  to  section  18.6. 


18.5.3.6  Relationship  Creation  Report  Service  Agreements 

This  service  uses  the  unconfirmed  M- EVENT -REPORT  CMIS 
service  to  convey  its  reporting  information.  It  also  uses 
the  event  reporting  control  Function  specified  in  section 
18.5.5.1  to  report  the  events. 

CMIS  M- EVENT-REPORT  request  parameters 

<invokeIdentif ier> 

<mode>  <unconf irraed> 

<managedObj ectClass>  Refer  to  section  18.6. 

<managed  Obj ectlnstance>  Refer  to  section  18.6. 

<eventType>  This  parameter  should  identify  the 

<RelationshipCreation>  Event  with  the 
object  identifier  defined  in  [OMF] . 

<eventArgument>  This  parameter  will  include  a set 

of  <relationship  attribute  name, 
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the  value  that  was  just  added  to 
its  set-value  list>. 


18.5.3.7  Relationship  Deletion  Report  Service  Agreements 

This  service  uses  the  unconfirmed  M- EVENT -REPORT  CMIS 
service  to  convey  its  reporting  Information.  It  also  uses 
the  event  reporting  control  Function  specified  in  section 
18.5.5.1  to  report  the  events, 

CMIS  M- EVENT -REPORT  request  parameters 

<invokeIdentif ier> 

<mode>  <unconf irmed> 

<managedOb j ectClass>  Refer  to  section  18.6. 

<managed  Obj ectlnstance>  Refer  to  section  18.6. 

<eventT}’pe>  This  parameter  should  identify  the 

<RelationshipDeletion>  event  type  with 
the  object  identifier  defined  in  [OMF] . 

<eventArguiiient>  This  parameter  will  include  a set 

of  <relationship  attribute  name, 
the  value  that  was  just  removed 
from  its  set-value  list>. 


18.5.3.8  Relationship  Change  Report  Service  Agreements 

This  service  uses  the  unconfirmed  M- EVENT -RE PORT  CMIS 
service  to  convey  its  reporting  information.  It  also  uses 
the  event  reporting  control  Function  specified  in  section 
18.5.5.1  to  report  the  events. 

CMIS  M- EVENT -REPORT  request  parameters: 

<invokeIdentif ier> 

<mode> 

<managedObj ectClass>  Refer  to  section  18.6. 
<managed  Obj ectlnstance>  Refer  to  section  18.6. 
<eventType>  This  parameter  should  identify  the 
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<RelationshipChanged>  Event  with  the 
object  identifier  defined  in  [OMF] . 

<eventArguiaent>  This  parameter  will  include  a set 

of  tuples  of  <relationship 
attribute  name  whose  set-value  was 
just  replaced,  the  old  member  value 
which  was  replaced,  the  new 
replacing  value>. 


18.5.3.9  The  usage  of  compound  Relationship  attributes 

’Group*  Agreements 

No  Relationship  <group>  attribute  is  to  be  used  in 
Relationship  Creation  and  Relationship  Changing  management. 
When  a relationship  <group>  attribute  is  used  in 
Relationship  Deletion  management,  all  relationship  attribute 
values  of  the  group  of  the  selected  managed  object  instances 
will  be  set  to  "null."  Use  of  the  Relationship  <group> 
attribute  is  permitted  for  Relationship  listing  and  Related 
Object  Listing.  Refer  to  [RMF]  for  more  detail. 

18.5.3.10  The  usage  of  the  combined  Add/Change /Delete 

Services 


It  is  possible  to  combine  the  Add,  Change,  Delete  services 
in  one  GMIS  operation,  but  until  its  complications  are  fully 
understood,  it  is  not  to  be  used  in  Phase  1. 

Editor’s  Note:  Need  an  example  here  to  show  the  ordering 
operations  on  attributes,  etc. 


18.5.4  Error  Reportins  and  Information  Retrieval 
Function: 


Editor's  Note:  Tutorial  Material.  Currently  there  are  two 

services  within  the  Error  Reporting  and 
Information  Retrieval  Function  standard  [ERIRF] 
that  provide  the  ability  to  report  errors  from  one 
open  system  to  another  system  and  to  retrieve 
information  from  an  open  system.  The  two  services 
are ; 


(1)  the  Error  Reporting  Service,  and 

(2)  the  Information  Retrieval  Service. 
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For  the  NMSIG  Phase  1 lAs , only  the  Error  Reporting  Service  of 
the  [ERIRF]  is  required. 


18.5.4.1  Errc r Reporting  Service  Agreements: 

Editor's  Note:  Tutorial  Material.  The  Structure  of 

Management  Information  standard  [MIM] 
specifies  that  managed  objects  may  emit 
notifications.  CMIS/CMIP  provides  the 

facility  for  reporting  such  notifications  to 
a managing  system.  The  Event  Forwarding 
Control  Function  of  the  Management  Service 
Control  standard  [MSG]  provides  the 
capability  of  forwarding  event  reports  to 
specified  destinations.  This  forwarding  is 
based  on  information  contained  within  the 
event.  The  Error  Reporting  Service  defines 
information  to  be  contained  in  the  event 
report.  This  information  is  provided  to  help 
with  understanding  the  cause  of  faults,  and 
other  information  related  to  its  side 
effects.  This  information  may  also  be 
referenced  within  an  event  forwarding 
discriminator  of  the  Event  Forwarding  Control 
Function  for  determining  if  and  where  error 
reports  should  be  sent. 

The  type  of  possible  errors  defined  in 
[ERIRF]  are: 

(1)  communicatiori  failure:  errors 
associated  with  the  process  of 
sending  information  from  one  system 
to  another.  Some  examples  are: 
loss  of  signal,  framing  error, 
transmission  error,  and  call 
establishment  error. 

(2)  quality  of  service  failure:  errors 
associated  with  the  degradation  in 
the  quality  of  performing  a 
specific  service  by  a service 
provider  to  a service  user.  Some 
examples  are:  response  time 
excessive,  queue  size  exceeded, 
bandwidth  reduced,  and 
retransmission  rate  excessive. 
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(3)  processing  failure:  errors 
associated  with  processing  input  to 
produce  the  desired  output.  This 
is  related  to  a software  fault. 

Some  examples  are:  storage  capacity 
problem,  version  mismatch, 
corrupted  data,  CPU  cycle  limit 
exceeded,  software  error,  and  out 
of  memory  error. 

(4)  equipment  failure:  errors 
associated  with  equipment  fault. 
Some  examples  are:  power  problem, 
timing  problem,  trunk  card  problem, 
line  card  problem,  processor 
problem,  terminal  problem,  external 
device  problem,  dataset  problem, 
and  multiplexer  problem. 

(5)  environmental  failure:  errors 
associated  with  a condition 
relating  to  an  enclosure  in  which 
the  communications  equipment 
resides.  The  errors  may  affect  the 
performance  of  the  equipment.  Some 
examples  are:  smoke  detection, 
enclosure  door  is  open,  high/low 
ambient  temperature,  high/low 
humidity,  and  intrusion  is 
detected. 

Editor's  Note:  The  above  description  is  very  general.  We 
need  contributions  to  further  define  the 
ProbableCauseCode . If  we  follow  the  standard, 
we  may  bite  off  having  to  explain  how  to 
categorize  every  error  type,  when  to  use 
each,  when  not  to  use  each,  what  precedence 
order  should  be  employed,  etc.  This  is  not  a 
small  task. 

The  following  sections  specify  the  Model,  the  Support 
Managed  Object  and  the  Error  Reporting  Service  for  the  Phase 
1 lAs . 
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18.5.4.1.1  Error  Reporting  Model  Agreements: 

For  the  Error  Reporting  Service,  the  Event  Reporting 
Control  Model  [sec.  18,5.5.1.1]  applies. 


18.5.4.1.2 Support  Managed  Object  Agreements: 

The  Event  Forwarding  Discriminator  oblect  is  defined  in 
[DSO] . 

18.5.4.1.3 Error  Reporting  Service  Agreements: 

The  following  agreements  and  clarifications  pertinent 
to  section  8.1  of  the  base  standard  [ERIRF]  and 
regarding  the  semantics  of  the  unconfirmed  CMIS  M~ 
Event-Report  service  (sec.  8.2.1  of  [CMIS])  are 
supported  by  the  Phase  1 network  management  lAs . All 
CMIS  parameters  are  mandatory,  except  where  noted 
below. 

CMIS  M- EVENT -REPORT  request  parameters: 


<invokeIdentif ier>  This  parameter  specifies  the 

M-Event-Report  operation 
invocation  identifier, 
it  is  to  be  used  to 
distinguish  this 
operation  from  others. 

<mode>  This  parameter  is  set  to  <unconf irmed>. 

<managedObj ectClass>  This  parameter  specifies 

the  managed  object  class 
of  the  managed  object 
instance  which  is 
reporting  an  error(s) . 

<managedObjectInstance>  This  parameter  specifies 

the  instance  of  the 
managed  object  that  is 
reporting  an  error(s) . 

<eventType>  This  parameter  specifies  the  type 
of  error  being  reported.  The  five 
possible  types  are: 

- Communication  Error 

- Quality  of  Service  Error 
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- Processing  Error 

- Equipment  Error 

- Environment  Error 

The  values  for  the  error  type  are 
defined  in  [ERIRF] . 

<eventTime>  This  parameter  specifies  the  time 
the  error(s)  occurred.  Reference 
section  18.6.2.3  for  further  lAs . 

<eventArgument>  For  the  network  management 

Phase  1 lAs , this  parameter  is 
optional.  The  fields  within 
the  parameter  are  also 
optional,  except  where  defined 
by  the  managed  object  class 
definition  [MIL]  or  specified 
in  the  [ERIRF],  [DM0]  or  [DMA] 
standards.  The  parameter  is 
present  if  at  least  one  of  the 
fields  below  is  present.  The 
possible  fields  are: 

<ProbableCauseCode>, 
<Severity>, 
<TrendIndication> , 
<Backups tatus> , 
<DiagnosticInfo>, 
<ThresholdInf o> , 
<StateChange>, 
<ProposedRepairAction>, 
and  <OtherInformatlon>. 


<ProbableCauseCode> 

This  field  contains  the  most  probable  reason 
for  the  error  indicated  in  the  eventType. 

<Severity> 

This  field  contains  the  level  of  network 
degradation  caused  by  the  named  error. 

Five  levels  of  severity  are  defined  by  the 
base  standard;  they  are:  critical,  major, 
minor,  warning,  and  indeterminate.  The 
values  for  the  Severity  code  are  defined  in 
Annex  A of  [DMA] . 

<TrendIndication> 

This  field  contains  the  current  trend  in  the 
type  of  error  being  reported.  There  are  two 
values  for  this  attribute:  TRUE,  implies 
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increase  in  severity,  FALSE,  implies  decrease 
in  severity,  as  defined  in  Annex  A of  [DMA] . 

<BackupStatus> 

This  field  contains  a value  which  indicates 
whether  the  failed  object  has  been  backed  up 
or  not.  There  are  two  possible  values  for 
this  field:  TRUE,  implies  backed  up,  and 
FALSE,  implies  not  backed  up,  as  defined  in 
Annex  A of  [DMA] . 

<DiagnosticInfo> 

This  field  contains  information  which  may 
assist  to  diagnose  the  fault. 

Editor's  Note:  Tutorial  Material.  Examples  of  such 
information  may  include  counter 
values,  threshold  values,  and 
configuration  state,  etc.  as 
defined  by  managed  object  class. 


<ThresholdInfo> 

This  field  contains  the  values  of  the 
threshold  which  caused  the  error  to  be 
generated.  The  subfields  are  defined  in 
[DMA] . 

<StateChange> 

This  field  contains  information,  defined  in 
Annex  A of  [DMA] , about  the  administrative 
and  operational  state  of  the  managed  object 
at  the  time  the  error  occurred. 

<ProposedRepairAction> 

This  field  contains  information  which  may 
propose  action  to  correct  the  fault. 

Editor's  Note;  Tutorial  Material.  This 

information  is  defined  by  the 
managed  object  class. 
<OtherInformation> 

This  field  contains  other  relevant 
information  about  the  managed  object  at  the 
time  the  error  occurred. 

Editor's  Note:  Tutorial  Material.  This  information 
is  defined  by  the  managed  object. 


18.5.4.2  Information  Retrieval  Function  Agreements: 
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18.5.4.2.1 Information  Retrieval  Service 

Agreements : 


18.5.5 Management  Service  Control  Functions  Agreements: 

Editor's  Note:  Tutorial  Material.  There  are  two  control 
functions  in  this  category  to  provide  the 
ability  to  specify  criteria  under  which  event 
operations  can  be  controlled.  The  two  functions 
are : 

(1)  Event  Reporting  Control  Function,  and 

(2)  Service  Access  Control  Function. 

The  NMSIG  Phase  1 network  management  agreements  support  only  the 
Event  Reporting  Control  Function.  The  Service  Access  Control 
Function  is  for  further  study. 


18.5.5.1  Event  Reporting  Control  Function  Agreements: 


Editor's  Note:  Tutorial  Material.  The  Event  Reporting 
Control  function  provides  services  by  which 
event  reporting  can  be  distributed  and 
controlled.  Event  report  distribution  means 
the  selection  of  chosen  events  to  be  reported 
to  some  designated  system(s)  or  process(es) 
within  some  selected  time  period.  These 
selections  are  done  by  a filtering  process 
using  the  "DiscriminatorCons truct"  attribute 
of  the  "Event  Forwarding  Discriminator" 
object.  Event  Reporting  Control  is  the 
ability  to  initiate,  terminate,  suspend,  or 
resume  event  reporting  through  the 
manipulation  of  an  Event  Forwarding 
object  specified  in  section 
In  addition.  Event  Reporting 
further  alter  event  report 
behavior  by  changing  the 
attributes  in  an  Event 
Discriminator  object 

BeginTime  and 


Discriminator 
18.5.5.1.1. 

Control  can 
distribution 
distribution 
Forwarding 
(DiscriminatorConstruct , 
EndTime  etc . . . ) . 


The  following  sections  contain  the  NMSIG  Phase  1 network 
management  agreements  pertaining  to  the  Event  Reporting 
Control  Model  [RMF] , the  Support  Managed  Object  to 
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facilitate  the  Event  Reporting  Control  Function  [RMF] , and 
the  following  services  (defined  in  [RMF]): 

o Initiate  event  reporting  service 

o Terminate  event  reporting  service 

o Suspend  event  reporting  service 

o Resume  event  reporting  service 

o Modify  event  forwarding  discriminator  attributes 

service 

o Retrieve  event  forwarding  discriminator  attributes 

service . 


18.5.5.1.1 Event  Reporting  Control  Model 

Agreements : 

The  Event  Reporting  Control  function  is  based  on  the 

following  assumptions,  pictured  below: 

(1)  There  is  (at  least)  one  managed  object 
capable  of  generating  notifications. 

(2)  There  exists  a conceptual  event  detection  and 
processing  function  which  receives  the  local 
notifications  and  forms  potential  event 
reports . 

(3)  There  exist  Event  Forwarding  Discriminator 
objects  which  are  used  for  determining 
whether  potential  event  reports  can  become 
real  event  reports  which  are  then  emitted 
from  the  open  system. 

(4)  There  exists  a conceptual  process  which 
guides  all  potential  event  reports  to  all 
Event  Forwarding  Discriminators  for 
evaluation. 

(5)  There  exists  a conceptual  process  which 
evaluates  the  potential  event  reports  using 
the  Event  Forwarding  Discriminator  attributes 
(DiscriminatorConstruct , BeginTime,  EndTime, 
Destination  ...)  to  determine  whether  the 
potential  event  reports  are  to  be  reported  to 
the  specified  destination  system(s) . 
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18.5.5.1.2 Support  Managed  Object  - Event 

Forwarding  Discriminator  Agreements 

Editor’s  Note:  Tutorial  Material.  The  Event  Report 

Discriminator  is  a management  service 
control  discriminator  which  is  a managed 
object  providing  for  specification  of 
criteria  relevant  to  selecting  events  of 
interest  to  be  reported  to  other  open 
systems.  The  criteria  must  be  satisfied 
by  potential  event  reports  related  to 
managed  objects  before  the  event  report 
is  forwarded  to  a particular 
destination.  That  destination  is  also 
specified  by  the  discriminator  and  is 
the  address  of  a remote  managing 
process . 

Editor's  Note:  Tutorial  Material.  The  Event  Forwarding 
Discriminator  has  the  following 
attributes : 

(1)  DiscriminatorlD : This  attribute 

uniquely  identifies  the 

discriminator. 

(2)  DiscriminatorConstruct : This 

attribute  specifies  the  conditions 
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which  define  when  an  event  report 
should  be  generated  after  a event 
occurs . Each  event  which  occurs  in 
an  event  generating  system  has  to 
be  evaluated  for  passing  the  filter 
construct.  Only  those  events  that 
pass  (match)  the  filter  will  result 
in  an  event  report  being  sent  to 
the  destination  system(s) , 

(3)  ManagementUserldentif ication:  This 
attribute  identifies  the  systems  on 
whose  behalf  the  event  report  is 
performed.  This  usually  indicates 
the  managing  system. 

Editor's  Note:  Should  the  Phase  1 
network  management  lA's 
limit  this  to  containing 
only  a single  system  at  a 
time?  This  would  mean  we 
would  not  require  use  of 
PDAD2  for  GMIS/P. 

(4)  Discriminator  State:  This  attribute 

specifies  the  state  in  which  the 
Event  Report  Discriminator  object 
is  to  be  created.  The 

Discriminator  object  may  be  created 
in  a "locked”  or  "unlocked"  state. 

(5)  Begin  Time:  This  attribute 
identifies  the  beginning  time  of  a 
24  hour  interval  during  which  the 
event  report  service  is  active. 

(6)  End  Time:  This  attribute 
identifies  the  ending  time  of  a 24 
hour  interval  during  which  the 
event  report  service  is  available. 

An  example:  If  Begin  Time  = 8:00  AM 
and  End  Time  = 5 PM,  then  event 
reports  will  only  be  sent  between 
the  hours  of  8:00  AM  through  5:00 
PM  on  the  basis  of  this 
discriminator . 

In  Phase  1 , one  Event  Forwarding  Discriminator  is 
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defined  for  each  destination  process  to  which  the  event 
reports  are  to  be  sent. 

18.5.5.1 .3  Initiate  Event  Reporting  Service 

Agreements : 

Note  to  the  Editor:  Tutorial  material  in  all  subsequent 

sections  needs  to  be  scanned  for 
scenario  information  and  that 
material  should  be  provided  to  the 
scenario  section  editor. 

Editor's  Note:  Tutorial  Material.  A user  at  a managing 
system  may  desire  that  particular  events 
generated  at  an  event  generating  system 
be  reported  to  a destination  system.  To 
achieve  this,  the  user,  from  the 
managing  system,  will  need  to  create 
Event  Forwarding  Discriminator  objects 
for  those  particular  events  with  the 
proper  parameters  at  the  event 
generating  system. 

Each  Event  Forwarding  Discriminator  object  must  include 
a DiscriminatorConstruct  which  specifies  the  desired 
filtering  conditions  under  which  the  designated  event 
should  be  reported  to  the  destination  system. 

A managing  system  must  issue  a single  M-CREATE  CMIS 
service  request  to  an  event  generating  system  to  create 
a single  Event  Forwarding  Discriminator.  Multiple 
discriminators  require  multiple  M-CREATE  CMIS  service 
requests . 

Editor'.s  Note:  Once  the  Event  Forwarding  Discriminator 
object  is  created,  is  there  an  implicit 
assumption  that  the  newly  created  object 
forms  part  of  the  context  implied  by  the 
current  association  context?  Can  the 
Event  Forwarding  discriminator  object  be 
managed  by  applications  using  other 
associations  other  than  the  one  over 
which  the  CMIS  M-CREATE  request  was 
issued,  or  do  they  need  to  reassociate? 
This  issue  will  be  determined  during  the 
association  policy  discussions. 

The  following  agreements  and  clarifications  pertinent 
to  section  8,1  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-CREATE  service 
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(sec.  8.3.4  of  [CMIS])  are  supported  by  the  Phase  1 
network  management  lAs.  All  CMIS  parameters  are 
mandatory,  except  where  noted  below. 


CMIS  M-CREATE  request  parameters: 


< invoke Identifier> 
<managedObjectClass> 


<managedObjectInstance> 


The  parameter  value  will 
always  be  the 
<Event  Forwarding 
Discriminator>  class. 

This  parameter  must  be 
included  in  the  request. 

(1)  If  this  parameter  is 
used  in  the  request, 
it  will  identify  the 
instance  of  the 
discriminator 
class  by  providing 
the  DiscriminatorlD 
and  names  of  any 
superiors . 


(2)  Otherwise,  the 

performing  CMISE- 
service-user  will 
assign  a value  to 
identify  the 
instance . 


Editor's  Note:  Should  we  agree  on  using  (1)  always 
in  the  request? 

Note  to  the  Editor:  Incorporate  comments  from  the 

Object  Creation  section,  later 
on. 

<accessControl>  Refer  to  section  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 


<referenceObj ectlnstance>  Refer  to  section 

18.6  (Management 
Communications)  of 
this  chapter  for 
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agreements 
pertaining  to  this 
parameter . 

<attributeList>  This  field  refers  to  the  Event 

Forwarding  Discriminator 
object  attributes  (sec. 

18.5.5.1.2  of  this  chapter). 
Any  attributes  provided  by  the 
CMIS-service-user  will  be  used 
to  initialise  the 
corresponding  attributes  for 
the  newly  created  instance. 

The  <discrlminatorState> 
attribute  is  set  to  "unlocked" 
by  default. 

CMIS  M-CREATE  response  parameters: 

<invokeIdentif ier> 

<managedObj ectClass>  Same  as  request 

<managedObj ectlnstance>  This  parameter  is  always 

returned  by  the  response 
to  Indicate  the  instance 
name  of  the  newly  created 
obj  ect . 

This  parameter  specifies  ALL 
the  object  attributes  and 
values  for  the  NEWLY  created 
Event  Forwarding 
Discriminator . 

Refer  to  section  18.6.2.3  and 

18.6.3.1.3  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  parameter. 


<attributeList> 


<currentTime> 


18.5.5,1.4  Terminate  Event  Reporting  Service 

Ascreements : 

Editor's  Note:  Tutorial  Material.  A user  in  a managing 
system  can  use  this  service  to  turn  off 
the  reporting  of  events  from  a specific 
event  generating  system. 
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To  achieve  that,  the  user  will  need  to 
delete  the  Event  Forwarding 

discriminator  object (s)  of  the  unwanted 
event (s)  on  the  system.  The  absence  of 
such  a discriminator  will  not  stop  the 
generation  of  potential  event  reports 
caused  by  the  managed  object,  it  simply 
disables  event  reporting  of  the 
particular  potential  events  from  the 
event  generating  system. 

A managing  system  must  issue  a single  M-DELETE  CMIS 
service  request  to  the  event  generating  system  to 
delete  exactly  one  Event  Forwarding  Discriminator. 
Multiple  M-DELETE  CMIS  service  requests  are  needed  to 
delete  multiple  discriminators. 

The  following  agreements  and  clarifications  pertinent 
to  section  8.2  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-DELETE  service 
(sec.  8.3.5  of  [CMIS])  are  supported  by  the  Phase  1 
network  management  lAs . All  CMIS  parameters  are 
mandatory,  except  where  noted  below. 


CMIS  M-DELETE  request  parameters: 

< invoke Identifier> 

<baseManagedObj  ectClass> 

<baseManagedObj  ectlnstance> 

<accessControl>  Refer  to  section  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 

<synchronizatlon>  <BestEffort>  is  required. 

<scope> 

<f ilter> 


CMIS  M-DELETE  response  parameters: 
<invokeIdentif ier> 
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<linkedldentif ier> 

<managedObjectClass>  Refer  to  section  18.6 
<managedObj  ectlnstance>  (Management 

Communications)  of  this 
chapter  for  agreements 
pertaining  to  these 
parameters , 

<currentTime>  Refer  to  section  18.6.2.3  and 
18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to 
this  parameter. 


18.5.5.1.5 Suspend  Event  Reporting  Service 

Agreements : 

Editor's  Note;  Tutorial  Material.  This  service 

temporarily  stops  event  reports  from 
being  sent  from  the  event  generating 
system  to  the  destination  system,  yet 
retains  the  ability  to  resume  the 
reporting  if  desired. 

To  suspend  event  reporting,  a managing  system  must 
issue  an  M-SET  CMIS  service  request  to  the  event 
generating  system  to  change  the  value  of  the 
<DiscriminatorState>  attribute  to  "locked." 

When  the  <DiscriminatorState>  attribute  is  "locked," 
any  events  that  would  normally  occur  for  this 
discriminator  are  discarded  and  NOT  queued  up  for  later 
transmission. 

The  following  agreements  and  clarifications  pertinent 
to  section  8.3  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-SET  service  (sec. 
8.3.2  of  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory, 
except  where  noted  below. 

CMIS  M-SET  request  parameters: 

<invokeIdentif ier> 

<mode> 
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<baseManagedObj  ectClass> 
<baseManagedObj  ectlnstance> 


<accessControl>  Refer  to  section  18.6.2.4  and 

18.6.3.1.2  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 

<synchronization>  <bestEffort>  is  required. 
<scope> 

<f ilter> 


<attributeList>  This  parameter  will  include 

the  Event  Forwarding 
Discriminator  attribute 
<discriminatorState>  with  the 
value  of  the  attribute  to  be 
"locked."  (See  sec.  18.5.5.1.2 
of  this  chapter) . 


CMIS  M-SET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObjectClass>  Refer  to  section  18.6 
<managedObj ectlnstance>  (Management  Communica- 
tions) of  this  chapter 
for  agreements  pertaining 
to  these  parameters. 

<currentTime>  Refer  to  section  18.6.2.3  and 
18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to  this 
parameter . 
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18.5.5.1.6  Resume  Event  Reporting  Service 

Agreements : 

Editor's  Note:  Tutorial  Material.  This  service  enables 
event  reporting  for  particular  types  of 
events,  thereby  permitting  events  to  be 
sent  from  a specific  event  generating 
system  to  a specific  destination  system. 
This  operation  is  used  to  resume  the 
reporting  of  events  that  was  previously 
suspended. 

To  resume  event  reporting,  the  managing  system  must 
issue  an  M-SET  CMIS  service  request  to  an  event 
generating  system  to  change  the  <discriminatorState> 
attribute  to  <Unlocked>. 

The  following  agreements  and  clarifications  pertinent 
to  section  8.4  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-SET  service  (sec. 
8.3.2  of  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory  and 
are  as  specified  in  section  18.5.5.1.5,  with  the 
following  difference: 

<attributeList>  This  parameter  will  contain  the 

Event  Forwarding  Discriminator 
attribute  <discriminatorState>. 

(See  sec.  18.5.5,1.2  of  this 
chapter) . The  value  of  the 
attribute  will  be  set  to 
"unlocked. " 


18.5.5.1.7 Modify  Event  Forwarding  Discriminator 

Attributes  Service  Agreements: 

Editor's  Note:  Tutorial  Material.  A managing  system 
can  change  the  conditions  of  event 
reporting  for  some  selected  events  by 
changing  the  values  of  the  Event 
Forwarding  Discriminator  attributes 
which  are  used  in  the  processing 
associated  with  event  distribution  and 
control.  For  example,  the  user  may  want 
to  move/modify  the  reporting  of  a 
specific  type  of  event  to  a different 
destination  system,  or  change  the 
frequency  of  the  event  reporting.  To 
achieve  such  results,  a managing  system 
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will  need  to  modify  the  value  of  the 
<managemen tU s e r I den t ification>  and/or 
<DiscriminatorConstruct>  attributes  to 
reflect  the  new  needs.  This  service  can 
be  used  for  locked  or  unlocked  Event 
Forwarding  Discriminator  objects. 

To  change  attributes  of  one  specific  Event  Forwarding 
Discriminator  in  one  specific  event  generating  system, 
a managing  system  must  issue  a single  M-SET  CMIS 
service  request  to  the  event  generating  system. 

Changes  to  multiple  discriminators  in  a single  event 
generating  system  require  multiple  M-SET  CMIS  service 
requests . 

The  following  agreements  and  clarifications  pertinent 
to  section  8.5  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-SET  service  (sec. 
8.3.2  of  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory, 
except  where  noted  below. 

CMIS  M-SET  request  parameters: 

<invokeIdentif ier> 


<mode> 


This  parameter  v;ill  be  set  to 
<confirmed>. 


<baseManagedObj  ec  tClass> 
<baseManagedObj  ectlnstance> 
<accessControl> 


<s3mchronization> 

<scope> 

<f ilter> 
<attributeList> 


Refer  to  sections  18.6.2.4  and 
18.6.3.1.2  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter, 

<bestEffort>  is  required. 


This  parameter  will  specify 
the  Event  Forwarding 
Discriminator  attributes  to  be 
modified.  The  modifiable 
attributes  are: 

<DiscriminatorConstruct>, 
<Management  User  Iden- 
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tification>,  <Dis- 
criminator  State>,  <Begin 
Time>,  <End  Tirae>. 

Editor's  note:  This  parameter  is  going  to  be 
replaced  by  the  <modificationList> 
parameter,  once  PDAD2  for  CMIS/P  is 
adopted. 

CMIS  M-SET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ier> 

<managedObj ectCla,ss>  Refer  to  section  18.6 
<managedObj  ectlnstance>  (Management 

Communications)  of 
this  chapter  for 
agreements  pertaining  to 
these  parameters. 

<attributeList>  This  parameter  will  specify 

the  Event  Forwarding 
Discriminator  attributes 
that  were  modified. 

<currentTime>  Refer  to  sections  18.6.2.3  and 
18.6.3.1.3  (Management 
Communications)  of  this  chapter 
for  agreements  pertaining  to  this 
parameter. 


18.5.5.1.8 Retrieve  Event  Forwarding  Discriminator 

Attributes  Service  Agreements: 

To  examine  the  Event  Reporting  Discriminator  parameters 
associated  with  a specific  event,  a managing  system 
must  issue  an  M-GET  CMIS  service  request  to  an  event 
generating  system  to  retrieve  the  values  of  specific 
discriminator  attributes. 

The  following  agreements  and  clarifications  pertinent 
to  section  8.5  of  the  base  standard  [MSC]  and  regarding 
the  semantics  of  the  confirmed  CMIS  M-GET  ser\’'ice  (sec. 
8.3.1  of  [CMIS])  are  supported  by  the  Phase  1 network 
management  lAs . All  CMIS  parameters  are  mandatory, 
except  where  noted  below. 
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CMIS  M-GET  request  parameters: 
<invokeIdentif ier> 
<baseManagedObj  ectClass> 
<baseManagedObj  ectlnstance> 


<accessControl> 

Refer  to  sections  18.6.2.4  and 
18.6.3.1.2  (Management 
Communications)  of  this 
chapter  for  agreements 
pertaining  to  this  parameter. 

<synchronization> 

<bestEffort>  is  required. 

<scope> 


<f ilter> 

<attributeIdList> 

This  parameter  will  specify 
the  Event  Forwarding 
Discriminator  attributes  to 
be  retrieved.  The  readable 
attributes  are: 

<Discr iminatorId> , 
<DiscriminatorConstruct>, 
<Management  User 

Identif ication>, 
<Discriminator  State>, 
<Begin  Time>,  <End  Time>. 

Default  gets  all  attributes. 

CMIS  M-GET  response  parameters: 

<invokeIdentif ier> 

<linkedldentif ler> 

<managedObjectClass>  Refer  to  section  18.6 
<managedObj  ectins tance>  (Management 

Communications)  of 


this  chapter  for 
agreements  pertaining  to 
these  parameters. 

<attributeList> 

This  parameter  will  specify 
the  retrieved  Event  Forwarding 
Discriminator  attributes. 
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18. 


<currentTime>  Refer  to  sections  18,6.2.3  and 

18.6.3.1.3  (Management 
Communications)  of  this  chapter  for 
agreements  pertaining  to  this 
parameter . 

18.5.5.2  Service  Access  Control  Function  Agreements: 

Editor* s Note:  This  section  is  for  future  study. 


6 Event  Logging  Control  Function  Agreements: 

18.5.6.1  Event 

Logging  Model  Agreements: 

18.5.6.2  Support  Managed  Obiect  Agreements: 

18.5.6.2.1 

Log  Discriminator  Agreements: 

18.5.6.2.2 

LOG  Agreements : 

18.5.6.3  Log  Control  Services  Agreements: 

18.5.6.3.1 

Initiate  Event  Logging  Service 

Agreements : 

18.5.6.3.2 

Terminate  Event  Logging  Service 

Agreements : 

18.5.6.3.3 

Suspend  Event  Logging  Service 

Agreements : 


18.5.6.3.4  Resume  Event  Logging  Service  Agreements: 


18.5.6.3.5  Modify  Event  Logging  Parameters  Service 

Agreements : 
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18.5.6.3.6 Event  Log  Parameters  Retrieval  Service 

Agreements : 


18.6  MANAGEMENT  COMMUNICATIONS 


This  section  identifies,  in  detail,  use  of  the  management 
communications  services  and  protocols,  based  on  the  standards 
defined  in  [CMIS],  [CMIP] , [ADDRMVS/P]  and  [CANGETS/P] . 

This  section  covers  the  agreements  pertaining  to  the  use  of 
associations  over  which  to  carry  management  PDUs , agreements 
pertaining  to  the  services  offered  to  a CMIS  Service  User 
(in  terms  of  the  functions  defined  in  sec.  18.5),  agreements 
pertaining  to  the  protocol  used  to  convey  the  management  PDUs, 
and  agreements  pertaining  to  the  services  required  of  other 
layers  in  order  to  convey  the  management  PDUs  defined. 


18.6.1 Association  Policies 


Editor's  note:  Tutorial  Material:  This  draft  of  the  Association 
Policy  section  of  the  Phase  1 lAs  represents  the 
output  from  an  interim  NMSIG  meeting  held  in 
Peabody  MA  in  November  1989.  The  purpose  of  the 
meeting  was  to  align  the  draft  section  from  the 
July  Workshop  with  output  from  the  Florence 
meetings  and  with  the  issues  from  the  NMSIG  Issue 
Log.  As  a result  of  review  by  the  December  1989 
OIW  NMSIG  Meeting,  some  additional  changes  were 
made  to  this  text. 

The  participants  at  the  interim  meeting  summarized 
the  issues  into  8 items.  These  are  listed  here  to 
enable  reviewers  to  understand  the  premise  for  the 
subsequent  text. 

Issue  1:  Should  there  be  agreements  about 

arbitration  among  competing  requests  where  agents 
allow  multiple  associations  to  managing  systems? 

It  was  decided  that  this  was  really  a matter 
for  an  agent  implementation.  If  an  agent 
does  some  form  of  arbitration  (eg; 
temporarily  lock  out  a request  to  modify  an 
object  while  a prior  request  is  being 
honored) , it  must  indicate  this  in  some 
agreed  upon  way  so  that  the  managing  system 
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can  distinguish  between  this  situation  and 
some  other  error,  such  as  access  denied  or 
no  such  object. 

This  issue  is  not  related  to  association 
types  or  to  access  control.  The 

recommendation  was  placed  in  an  appropriate 
section  of  the  CMIS/P  agreements  in  18.6.3. 

Issue  2:  What  is  the  retry  policy,  if  any? 

It  was  proposed  that  we  make  some  suggestions 
and  have  them  reviewed  by  the  Workshop . See 
section  18.6.1.4. 

Issue  3:  What  are  the  connect  and  disconnect 
policies,  if  any? 

See  section  18.6.1.4. 

Issue  4:  How  are  the  roles  of  managing  and  managed 
system  determined? 

It  was  felt  that  it  was  necessary  to 
determine  which  role  a system  is  playing  on 
an  association  and  that  the  Application 
Context  Name  work  in  the  Arhus  output  for  SMO 
fit  the  bill.  See  section  18.6.1.2. 

Issue  5:  Handling  of  events  vs  command/control. 

Issue  6:  Handling  of  monitoring  vs  control. 

Re  Issues  5 and  6,  it  was  felt  that  managed 
and  managing  systems  may  wish  to  restrict  the 
types  of  functions  that  may  be  performed  on  a 
particular  association.  The  proposal  for 

addressing  this  issue  is  in  section  18.6.1.2. 

Issue  7:  Views  of  a MIB  on  an  association. 

It  was  decided  to  keep  the  output  from  the 
July  workshop  which  states  that  we  make  no 
agreements  regarding  the  scope  of  an 

association  as  it  applies  to  the  objects  made 
accessible  over  that  association.  The 

arbitration  process  adds  a slight  wrinkle 

though.  See  section  18.6.1.4. 

Issue  8:  Are  we  making  recommendations  or 

requirements? 
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This  draft  has  both.  It  was  never  really 
decided  if  recommendations  are  appropriate  in 
these  agreements.  If  they  aren't  then  we 
will  have  to  decide  whether  to  drop  the 
recommendations  in  this  draft  or  make  them 
requirements . 

Associations  are  established  using  the  procedures  described  in 
[ACSEP]  with  recommendations  and  extensions  described  in  these 
implementation  agreements. 

Phase  1 lAs  specify  the  different  types  of  associations  that  may 
be  established  between  managing  and  managed  systems  (see 

18.6.1.2) .  The  type  of  a given  association  is  determined  by  the 
exchange  of  appropriate  application  context  information  between 
the  systems  using  a negotiation  process. 

Phase  1 lAs  recommend  that  managed  systems  reseirve  resources 
for  at  least  one  association  for  event  reporting  (see 

18.6.1.3)  . 

Phase  1 lAs  require  the  use  of  A-RELEASE  instead  of  A-ABORT. 

Phase  1 lAs  also  make  recommendations  regarding  parameters 
affecting  the  scope  of  managed  objects  and  span  of  time 
for  an  association  and  synchronization  among  multiple 
associations  (see  18.6.1.4). 

Phase  1 lAs  specify  the  access  control  information  to  be  used  in 
the  establishment  of  an  association  (see  18.6.1.5). 


18.6.1.1  ACSE  Services 

The  A-ASSOCIATE  and  A-RELEASE  ACSE  services  are  used  as 
specified  in  [ACSE] . The  Phase  1 lAs  make  certain 
requirements  as  to  the  use  of  the  APDU  fields  noted  below. 
Usage  of  all  other  fields  is  left  to  the  implementor. 

AE-TITLE  (Calling  AP  Title  and  Calling  AE  Qualifier)  usage 
is  specified  in  18.6.1.2. 

Application  Context  Name  usage  is  specified  in  18.6.1.2. 

ACSE  User  Information  consists  of  three  parameters 
(specified  in  [CMIS]):  Functional  Units,  Access  Control  and 
CMIS  User  Information.  Refer  to  section  18.6.3  for 
agreements  relating  to  Functional  Units.  Refer  to  section 
18.6.1.5  for  agreements  relating  to  Access  Control.  The 
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Phase  1 lAs  make  no  agreements  relating  to  CMIS  User 
Information. 


18.6.1.2  Association  Types 


The  Phase  1 lAs  specify  that  four  types  of  association  may 
be  negotiated  between  managing  and  managed  systems.  These 
types  are : 


Event 


Event/Monitor 


M-EVENT-REPORTs  may  be  sent  by  the 
managed  system;  no  other  CHIP  PDUs 
are  allowed 

same  as  Event  type  except  that,  in 
addition,  the  managing  system  may 
also  issue  M-GET  requests  and 
receive  M-GET  responses  over  the 
association 


Monitor/Control  managing  system  may  issue  M-GET, 

M-SET,  M- CREATE,  M- DELETE  and 
M-ACTION  requests  over  the 
association;  no  event  reporting  is 
allowed 


Full  Mgr/Agent  all  functions  must  be  supported 


The  negotiation  process  specified  for  the  Phase  1 lAs  uses 
the  A-ASSOCIATE  and  A-RELEASE  services  as  specified  in 
[ACSEP] . Application  Context  Name  [SMO]  is  used  to 
determine  the  requestor's  "role"  in  an  association  (managing 
or  managed  system)  and  to  determine  the  type  of  the 
association.  The  following  negotiation  rules  are  specified 
by  the  Phase  1 lAs : 

Editor's  Note:  The  SIG  left  open  the  question  of  using 
Application  Context  Names  for  both  role  and 
type  determination.  The  editor  investigated 
further  to  find  out  if  there  were  any 
restrictions  that  would  prevent  such  usage. 
Having  found  no  restrictions,  the  editor 
updated  the  text  to  provide  more  detail  in 
this  direction. 


Editor's  Note:  We  need  to  assign  Application  Context  Names. 

I suggest  that  we  register  appropriate  object 
names  under  the  NMSIG  arc.  I'll  take  a stab 
at  the  proper  format  (see  RASIG  output ...  sec . 
6 of  the  Working  Document)  and  propose  some 
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names  as  a placeholder  until  we  determine  the 
actual  format/names . (Wordsmi thing  and 

format  advice  are  welcome.) 

{iso(l)  identified-organization(3)  oiw(14) 
nmsig(2) 

manager-event-association(x) } 

{iso(l)  identif ied-organization(3)  oiw(14) 
nmsig(2) 

manager-event-monitor-association(x) } 

{iso(l)  identif ied-organization(3)  oiw(14) 
nmsig(2) 

manager-monitor-control-association(x) ) 

{iso(l)  identif ied-organization(3)  oiw(14) 
nmsig(2)  manager-full-associationTx) } 

{iso(l)  identif ied-organization( 3)  oiw(14) 
rimsig(2)  agent-event-association(x)  ) 


Editor's  Uote:  Tutorial  Material;  Ref:  [SMO]  Annex  A 

The  Application  Context  Name  (ACN)  indicates 
the  role  of  the  initiator  of  an  association. 
The  responder  may  alter  the  type  indication 
to  request  a change  in  the  type.  Note  that 
the  proposed  ACNs  above  follow  the  agreements 
on  which  system  may  request  a particular  type 
of  association.  Thus  there  is  a single  agent 
initiated  ACN  since  agents  (managed  systems) 
may  only  initiate  event  reporting 
associations . 

The  ACNs  in  these  agreements  refine  those 
defined  in  Annex  A [SMO]  and  are  used  in  the 
same  fashion. 

Editor's  Note:  We  will  need  to  add  text  relating  to 
negotiation  of  System  Management  Function 
functional  units  as  changes  to  this  section 
as  the  relevant  standards  (10164-*)  are 
updated.  It  is  anticipated  that  the  work  in 
N740  will  be  used  as  the  basis. 

1.  A taanaged  system  may  only  request  an  Event 

association  and,  in  fact,  must  create  an  Event 


( 
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association  if  it  has  an  event  to  report  and  no 
suitable  association  already  exists. 

2.  Managing  systems  may  request  any  association  type. 

3.  An  association  is  created  by  the  requesting  system 
issuing  an  A-ASSOCIATE  request  with  the 
requestor's  AE-TITLE  and  the  desired  application 
context.  The  responding  system  then  returns 
either  1)  an  A-ASSOCIATE  response  with  the 
requestor's  AE-TITLE  and  the  application  context 
which  it  wishes  to  accept  or  2)  an  A-ASSOCIATE 
response  rejecting  the  association. 

4.  Managed  systems  may  negotiate  "downward”  from 
Full  to  Monitor/Control , Event/Monitor  or  Event  by 
returning  the  new  application  context  in  the 
A-ASSOCIATE  response  to  the  managing  system  during 
the  association  creation  process.  In  the  same 
fashion,  managed  systems  may  negotiate  from 
Event/Monitor  to  Event. 

5.  When  a managing  system  receives  an  application 
context  in  an  A-ASSOCIATE  response  that  differs 
from  the  context  sent  in  an  A-ASSOCIATE  request  it 
may  either  proceed  with  the  new  context  or  refuse 
the  new  context  by  issuing  an  A-RELEASE  request. 

Editor's  Note:  A-RELEASE  is  used  when  the  requestor  does  not 
agree  with  the  new  context.  A- ABORT  is  used 
for  invalid  negotiation. 

Note  that  a system  may  play  both  managing  and  managed  system 
roles,  but  not  on  the  same  association. 

18.6.1.3  Events 

Phase  1 lAs  recommend  that  managed  systems  make  resources 
available  for  at  least  one  association  for  the  purposes  of 
event  reporting.  The  resources  allocated  to  an  association 
should  be  re-useable.  That  is,  if  the  system  must  report  an 
event  to  multiple  managers,  it  may  have  to  repeatedly 
utilize  the  resources  for  an  association  to  each  of  the 
managing  systems.  This  recommendation  is  made  to  ensure 
that  events  are  not  lost  due  to  a lack  of  associations. 

Editor's  Note;  The  status  of  18.6.1.3  as  a recommendation 
rather  than  a requirement  is  open  for 
coE'jiEents . 
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18.6.1.4  Scope/Span  of  an  Association 

Editor's  Note:  Discussions  at  the  Florence  meeting  indicate 
the  potential  for  an  "association  policy 
object.”  This  object  would  allow  for  the 
maintenance  of  parameters  pertaining  to  the 
behavior  of  an  association.  These  parameters 
would  include  such  things  as  number  of 
retries  and  inactivity  timers.  This  version 
of  section  18.6  was  written  so  that  if  this 
proposal  comes  to  fruition,  the  agreements 
can  be  migrated  to  the  ap- object  by 

"transferring"  the  parameters  to  the  object 
Itself. 

The  Phase  1 lAs  specify  no  process  for  negotiating  the  scope 
of  an  association  as  it  pertains  to  the  objects  that  may  be 
managed  within  the  context  of  that  association. 

Editor's  Note:  Text  in  the  December  1989  Workshop  draft 

document  regarding  arbitration  between 

requests  from  multiple  managers  was  moved 
from  this  section  to  the  CMIS/P  section  (sec. 
18.6.3) . 

The  Phase  1 lAs  specify  no  process  for  negotiating  a time 
span  of  an  association.  The  managing  or  managed  system  may 
terminate  an  association  based  upon  an  implementation 
specific  algorithm  governing  association  durations. 

Editor's  Note:  Text  in  the  December  1989  Workshop  draft 

document  regarding  potential  parameters  for 
managing  time  span  and  retries  for 

associations  was  removed  from  this  section. 
The  text  has  been  retained  "off-line"  at  the 
direction  of  the  NMSIG. 

underlying  services  such  as  ACSE  may  also 
cause  the  termination  of  an  association. 

The  Phase  1 lAs  require  that  associations  be  terminated  with 
A-RELEASE  to  avoid  loss  of  information  in  an  association. 

Editor's  Note:  Tutorial  Material:  If  A-ABORT  is  used  to 

terminate  an  association,  there  exists  a 
potential  for  loss  of  information  such  as 
pending  events  or  confirmations.  A-ABORT 
must  be  used,  however,  when  a protocol 
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violation  occurs  or  where  an  association  is 
not  yet  established. 


18.6.1.5  Other  Aspects  of  Associations 

Editor's  Mote:  The  access  control  information  in  this 
section  is  based  on  some  notes  from  a joint 
NMSIG/Security  SIG  meeting  that  took  place 
some  time  ago.  We  should  review  this  with 
the  Security  SIG  to  make  sure  we  are  still  in 
agreement  and  get  more  information  on  usage 
and  encoding.  This  review  is  tentatively 
planned  for  the  March  1990  OIW. 

The  Phase  1 lAs  specify  that  the  following  information  may 
be  used  in  establishing  an  association.  A managed  system, 
if  it  requires  access  control  information,  must  use  this 
format . 

Unused  fields  must  contain  nulls. 

Field  Name  Purpose 


1 Length  length  of  access  control  data 

2 Initiating 
Person 

3 Process  Type 

4 Process  ID 

5 Authorization  password 

6 Access  Privileges 

7 Audit 
Requirements 

8 Integrity 
Seal 


9 Optional 

Information 


universal  closed  community 
checksum;  message  authenti- 
cation code 

0-n  bytes  of  optional  data 


18.6.2 General  Agreements  on  Users  of  CMIS 
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These  agreements  are  based  on  the  standard  defined  in  [CMIS]  and 
[CMIP]  and  constrain  the  users  of  CMIS  services  and  not  the 
implementation  of  CMIP  itself. 


18.6.2.1  Object  Naming 

Object  Naming  will  be  accomplished  using  Distinguished  Names 
as  specified  in  section  18,7.2, 


18,6.2.2  Multiple  Object  Selection 

Multiple  Object  Selection  applies  to  all  management 
operations  except  Event  Report  and  Create. 


18.6.2.2.1  Scoping 

These  network  management  lAs  specify  that  scoping  will 
be  used  as  specified  in  [CMIS]  6.5.1,  8. 3. 1.1. 5, 

8. 3. 2. 1.6,  8. 3. 3. 1.6,  8. 3. 5. 1.5. 

18.6.2.2.2  Filtering 

These  network  management  lAs  specify  that  filtering 
will  be  used  as  specified  in  [CMIS]  6.5.2,  8. 3. 1.1. 6, 

8. 3. 2. 1.7,  8. 3. 3. 1.7,  8. 3. 5. 1.6. 

If  a system  receives  a filter  parameter  that  it  is 
unable  to  process,  it  must  return  the  error 
' complexityLimitation' , including  the  CMISFilter 
requested. 

If,  in  the  process  of  filtering  from  a set  of  selected 
entities,  there  are  no  managed  objects  selected,  the 
system  must  return  an  empty  reply  consisting  of  an 
Invoke  ID  and  no  response  argument. 


18.6.2.2.3 Synchronization 

In  order  to  support  interoperability  between  managing 
systems  and  managed  systems,  these  network  management 
lAs  define  that  the  default  synchronization  (i.e., 
BestEffort)  must  be  supported  by  all  conforming 
systems.  Atomic  synchronization  may  also  be  supported 
as  an  option. 
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If  a performer  is  unable  to  comply  with  a 
synchronization  request  specified  by  an  invoker,  the 
performer  must  return  the  error  ' syncNotSupported'  with 
the  parameter  indicating  the  synchronization  not 
supported. 


18.6.2.2.4 Linked  Replies 

These  network  management  lAs  specify  the  use  of  linked 
replies  as  specified  in  [CMIS]  7.1,  7.2.3. 


18.6.2.2.5 Request  Collision  Handling 

A managed  system  may  optionally  implement  an  algorithm 
for  preventing  collision  among  multiple  requests.  If 
this  algorithm  temporarily  rejects  one  or  more 
requests,  the  managed  system  must  reject  with  a 
' resourceLimitation'  error. 


18.6.2.3  Current/Event  Time 

The  time  if  provided,  should  be  as  close  as  possible  to,  but 
not  before,  the  actual  time  the  operation  occurred  in  order 
to  provide  the  most  accurate  timestamp  for  temporal  ordering 
of  operations  and  events  on  a single  open  system. 

For  these  network  management  lAs , the  encoding  of  the 
Current  Time  parameters  is  ASN.l  Generalised  Time,  UTC  Type, 
as  specified  in  [ASNl]  clause  32.3,  b)  and  c) , with  the 
precision  of  the  time  representation  indicating  the 
granularity  of  the  time  measurement.  For  example,  the  string 
19890613123012.333-0500  represents  a local  time  of  12:30:12 
(and  333  msecs)  on  13th  June  1989,  in  a time  zone  which  is  5 
hours  behind  GMT. 


18.6.2.4  Access  Control 


Conformant  implementations  are  not  required  to  use  this 
field.  The  Access  Control  field,  if  provided  by  the  invoker 
in  CMIP  PDUs , may  be  ignored  by  responding  systems  which  do 
not  support  access  control.  These  systems  must  not  reject  a 
PDU  on  the  basis  of  the  presence  of  access  information.  The 
invoker  may  interpret  this  as  acceptance  of  the  access 
control  parameter. 
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18.6.2.5  CMIS  Functional  Units 


Only  the  Kernel  Functional  Unit  must  be  supported.  Other 
functional  units  except  Extended  Service  are  optional  and 
their  use  must  be  negotiated  as  specified  in  [CMIS] . 
Extended  Service  is  not  within  the  scope  of  these 
agreements.  Negotiation  for  its  "non  use"  must  be 
supported. 


18.6.2.6  CMIP  Parameters 


The  CMIP  globalForm  must  be  used  for  the  following 
parameters : 

action  type  id 
attribute  id 
event  type  id 
object  class 

Use  of  localForm  is  outside  the  scope  of  these  agreements. 


18.6.3 Specific  Agreements  on  Users  of  CMIS 

These  agreements  are  based  on  the  standard  defined  in  [CMIS]. 

The  agreements  in  this  section  have  been  defined  in  terms  of 
those  capabilities  necessary  to  support  the  functions  and 
services  defined  in  section  18.5  (Management  Functions  and 
Services)  and  in  terms  of  the  Association  Policies  defined  in 
section  18.6.1.  These  agreements  constrain  the  users  of  CMIS 
services  and  not  the  implementation  of  CMIP  itself. 

The  parameter  presence  information  in  the  tables  in  this  section 
are  repeated  from  [CMIS]  and  have  the  same  meaning  as  in  the 
standard.  They  are  repeated  for  reader  convenience. 


18.6.3.1  M- Event -Report 

The  following  agreements  and  clarifications,  pertinent  to 
section  8.2.1  of  the  base  standard  [CMIS]  and  section  6.3  of 
the  base  standard  [CMIP]  and  regarding  the  M- EVENT -REPORT 
service,  are  included  within  these  network  management  lAs . 

Section  18.5  (Management  Functions  and  Services)  defines  the 
various  types  of  Event  Reports  that  may  be  sent. 

18.6.3.1.1 Event  Argument 
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All  arguments  defined  for  the  particular  event  type  of 
the  managed  object  class  (see  sec.  18.7,  Management 
Information  Agreements)  for  the  M-EVENT~REPORT  must  be 
supplied  in  the  Event  Argument  parameter. 


Item 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 


18.6.3.1.2  Parameter  Aareements 

Table  18.1.  M-EVENT  REPORT  Parameters 


Parameter  Name 


Req/Ind  Rsp/Gonf  Text  Reference 


Invoke  Identifier  M 

Mode  M 

Managed  Object  Class  M 

Managed  Object  Instance  M 

Event  Type  M 

Event  Time  U 

Event  Information  U 

Current  Time 
Event  Reply 
Errors 


M=  18.6.4 

U 18.6.2.6 

U 18.6.2.1 

C=  18.6.2.6 

18.6.2.3 
18.6.3.1.1 
U 18.6.2.3 

C 
C 


18.6.3.2  M-Get 

The  following  agreements  and  clarifications,  pertinent  to 
section  8.3.1  of  the  base  standard  [CMIS]  and  section  6.4  of 
the  base,  standard  [CHIP]  and  regarding  the  M-GET  service, 
are  included  within  these  network  management  lAs. 


18.6.3.2.1  Successful  Response 

For  a successful  M-GET  operation,  the  performer  shall 
return  (in  the  Attribute  List  parameter)  either  the 
attribute  values  for  all  attributes  explicitly 
requested  (in  the  Attribute  Identifier  List  parameter), 
or  the  attribute  values  for  all  attributes  defined  for 
the  managed  object(s)  selected  (if  the  Attribute 
Identifier  List  is  omitted) . 


18.6.3,2.2  Partially  Successful  Response 

For  a partially  successful  M~GET  operation,  where  only 
some  attribute  values  were  retrieved,  the  performer 
shall  return  (in  the  Errors  parameter,  specifically 
encoded  as  GetListError)  all  attribute  ids  and  their 
corresponding  values  that  wexe  successfully  retrieved 
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from  the  set  of  attributes  selected  as  described  above, 
together  with  all  attribute  ids,  and  the  corresponding 
error  codes,  for  each  of  the  attributes  for  which 
errors  were  detected.  All  attributes  requested  by  the 
invoker  must  be  processed,  with  either  a value  or  an 
error  code  returned  for  each. 


18,6.3.2.3 Linked  Rep lies 

For  the  final  reply  of  a series  of  linked  relies  or  the 
single  reply  where  no  objects  were  selected  when 
filtering  has  been  specified,  the  GetResult  is  omitted. 
Hence  Managed  Object  Class,  Managed  Object  Instance, 
Current  Time,  Attribute  List  and  Errors  are  all  omitted 
in  these  cases. 


18.6.3.2.4 Parameter  Agreements 


Table  18.2.  M-GET  Parameters 


Item  Parameter  Name 


Req/Ind  Rsp/Conf  Text  Reference 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 


Invoke  Identifier  M 

Linked  Identifier 
Base  Object  Class  M 

Base  Object  Instance  M 

Scope  U 

Filter  U 

Access  control  U 

Synchronization  U 


Attribute  Identifier  List  U 
Managed  Object  Class 
Managed  Object  Instance 
Current  Time 
Attribute  list 


14  Errors 


M 18.6.4 

C 18.6.4 

18.6.2.6 
18.6.2.1 
18.6.2.2.1 
18.6.2.2.2 
18.6.2.4 
18.6.2.2.3 
18.6.2.6 
C 18.6.2.6 

C 18.6.2.1 

U 18.6.2.3 

C 18.6.2.6, 

18.6.3.2.1, 
18.6.3.2.3 
C 18.6.3.2.2 


18.6.3.3  M-Set 

The  following  agreements  and  clarifications,  pertinent  to 
section  8.3.2  of  the  base  standard  [CMIS]  and  section  6.5  of 
the  base  standard  [CHIP]  and  regarding  the  M-SET  service, 
are  included  within  these  network  management  lAs. 
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18.6.3.3.1  Successful  Response 

For  a successful  M-SET  confirmed  operation,  the 
performer  shall  return  (in  the  Attribute  List 
parameter)  the  attribute  values  for  all  attributes 
explicitly  specified  (in  the  Attribute  List  parameter) 
indicating  their  new  values. 


18.6.3.3.2 Partially  Successful  Response 

For  a partially  successful  M-SET  operation,  where  only 
some  attribute  values  were  modified,  the  performer 
shall  return  (in  the  Errors  parameter,  specifically 
encoded  as  SetListError)  all  attribute  ids  and  their 
corresponding  values  that  were  successfully  modified 
from  the  set  of  attributes  ids  and  values  supplied,  and 
all  attribute  ids  and  the  corresponding  error  codes  for 
each  of  the  attributes  for  which  errors  were  detected. 
All  attributes  requested  by  the  invoker  must  be 
processed,  with  either  a value  of  an  error  code 
returned  for  each. 


18.6.3.3.3 Linked  Replies 

For  the  final  reply  of  a series  of  linked  relies  or  the 
single  reply  where  no  objects  were  selected  when 
filtering  has  been  specified,  the  SetResult  is  omitted. 
Hence  Managed  Object  Class,  Managed  Object  Instance, 
Current  Time,  Attribute  List  and  Errors  are  all  omitted 
in  these  cases . 


18.6.3.3.4  DAD2  Response 

Where  multi-valued  attributes  are  involved  in  an  M-SET 
operation,  the  values  returned  after  any  modification 
operation  must  be  the  full  set  of  values  of  that 
attribute  and  not  just  the  values  that  were  modified 
(e.g.,  added  or  removed). 

18.6.3.3.5  Parameter  Agreements 

Table  18.3.  M-SET  Parameters 

Item  Parameter  Name  Req/Ind  Rsp/Conf  Text  Reference 

1 Invoke  Identifier  M M 18.6.4 


18-87 


March  1990  (Working) 


Linked  Identifier 
Mode  M 

Base  Object  Class  M 

Base  Object  Instance  M 

Scope  U 

Filter  U 

Access  Control  U 

Synchronization  U 

Managed  Object  Class 
Managed  Object  Instance 
Modification  List  M 


Attribute  List 


Current  Time 
Errors 


C 18.6.4 

18.6.2.6 
18.6.2.1 
18.6.2.2.1 
18.6.2.2.2 
18.6.2.4 
18.6.2.2.3 
C 18.6.2.6 

C 18.6.2.1 

18.6.2.6, 

18.6.3.3.1, 
18.6.3.3.3, 
18.6.3.3.4 
U 18.6.2.6, 

18.6.3.3.1, 
18.6.3.3.3 
U 18.6.2.3 

C 18.6.3.3.2 


18.6.3.4  M-Action 


The  following  agreements  and  clarifications,  pertinent  to 
section  8.3.3  of  the  base  standard  [CMIS]  and  section  6.6  of 
the  base  standard  [CMIP]  and  regarding  the  M-ACTION  service, 
are  included  within  these  network  management  lAs. 


18.6.3.4.1 


When  multiple  objects  are  selected  for  an  M-ACTION 
operation,  there  is  no  ordering  implied  between 
selected  objects.  If  the  ordering  is  important,  the 
requesting  system  may  use  separate  operations,  for 
individual  object  instances,  in  the  desired  order. 


Table  18.4.  M-ACTION  Parameters 


Parameter  Name 


Req/Ind  Rsp/Conf  Text  Reference 


Invoke  Identifier  M 

Linked  Identifier 
Mode  M 

Base  Object  Class  M 

Base  Object  Instance  M 

Scope  U 

Filter  U 

Managed  Object  Class 


Managed  Object  Instance 


M 18.6.4 

C 18.6.4 

18.6.2.6 
18.6.2.1 
18.6.2.2.1 
18.6.2.2.2 
C 18.6.2.6 

C 18.6.2.1 
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10 

Access  Control 

U 

- 

18.6.2.4 

11 

Synchronization 

U 

- 

18.6.2.2.3 

12 

Action  Type 

M 

C(=) 

18.6.2.6 

13 

Action  Information 

U 

- 

14 

Current  Time 

- 

u 

18.6.2.3 

15 

Action  Reply 

- 

c 

16 

Errors 

- 

c 

18.6.3.3.2 

18,6.3.5  M-Create 

The  following  agreements  and  clarifications,  pertinent  to 
section  8.3.4  of  the  base  standard  [CMIS]  and  section  6.7  of 
the  base  standard  [CMIP]  and  regarding  the  M-CREATE  service, 
are  included  within  these  network  management  lAs . 


18.6.3.5.1 Managed  Object  Instance 

The  Managed  Object  Instance  request  parameter  may  be 
present  or  absent  depending  on  whether  the  invoker 
supplies  the  instance  name  or  the  performer  assigns  the 
instance  name  automatically.  The  definition  of  each 
Managed  Object  Class  shall  define  whether  the  instance 
name  may  be  supplied  by  the  invoker,  or  must  be 
assigned  by  the  performer.  This  definition  shall  apply 
to  every  management- initiated  creation  of  instances  of 
that  managed  object  class. 


18.6.3.5.2 Attribute  Values 

The  values  of  each  of  the  attributes  of  the  newly 
created  object  are  derived  in  the  following  order, 
where  each  bullet  may  overide  a value  provided  in  a 
previous  bullet: 

o From  the  default  value  defined  for  the 
attribute  in  the  managed  object  class 
definition,  if  any 

o From  the  corresponding  value,  if  any,  derived 
from  the  reference  object,  if  provided 

o From  the  value  provided  in  the  Attribute  List 
request  parameter. 

If  none  of  these  methods  provides  a value  for  any  one 
attribute,  then  the  operation  shall  be  considered  to 
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have  failed,  i.e.,  no  new  instance  is  created,  and  the 
error  code  'Missing  Attribute  Value'  shall  be  returned. 


18.6.3.5.3 Parameter  Agreements 

Table  18.5.  M-CREATE  Parameters 


Item 

Parameter  Name 

Rea/Ind 

Rso/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

2 

Managed  Object  Class 

M 

C 

18.6.2.6 

3 

Managed  Object  Instance 

U 

C 

18.6.2.1, 

18.6.3.5.1 

4 

Superior  Object  Instance 

U 

- 

5 

Access  Control 

U 

- 

18.6.2.4 

6 

Reference  Object  Instance 

U 

- 

18.6.2.6 

7 

Attribute  List 

U 

c 

18.6.2.6, 

18.6.3.5.2 

14 

Current  Time 

- 

u 

18.6.2.3 

16 

Errors 

- 

c 

18.6.3.5.2 

18.6.3.6  M-Delete 

The  following  agreements  and  clarifications,  pertinent  to 
section  8.3.5  of  the  base  standard  [CMIS]  and  section  6.8  of 
the  base  standard  [CMIP]  and  regarding  the  M-DELETE  service, 
are  included  within  these  Phase  1 network  management  lAs . 

18.6.3.6.1 Deletion  of  Objects  Containing  Objects 

The  error  'Processing  Failure'  must  be  returned  if  a 
managed  object  has  existing  contained  objects  and  the 
behavior  defined  for  that  object  prohibits  its  deletion 
unless  all  contained  objects  have  been  deleted. 


18.6.3.6.2 Parameter  Agreements 

Table  18.6.  M-DELETE  Parameters 


Item 

Parameter  Name 

Rea/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M 

18.6.4 

2 

Linked  Identifier 

- 

C 

18.6.4 

4 

Base  Object  Class 

M 

- 

18.6.2.6 

5 

Base  Object  Instance 

M 

- 

18.6.2.1 

6 

Scope 

U 

- 

18.6.2.2.1 

7 

Filter 

U 

- 

CM 

CM 

CM 

VO 

00 
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8 Access  Control 

9 Synchronization 

10  Managed  Object  Class 

11  Managed  Object  Instance 

12  Current  Time 

13  Errors 


U 

U 


C 

C 

U 

C 


18.6.2.4 


18.6.2.2.3 


18.6.2.6 

18.6.2.1 

18.6.2.3 


18.6.3.6.1 


18.6.4 Specific  Agreements  on  CMIP 


These  agreements  are  based  on  the  standard  defined  in  [CMIP] . 

The  agreements  in  this  section  have  been  defined  in  terms  of 
those  capabilities  necessary  to  support  the  functions  and 
services  defined  in  section  18.5  (Management  Functions  and 
Services)  and  in  terms  of  the  Association  Policies  defined  in 
section  18.6.1. 

These  network  management  lAs  make  no  agreements  beyond  the 
specifications  in  [CMIP]  except  the  following; 

18.6.4.1  Invoke /Linked  Identifier  Size 

Invoke  Identifiers  and  Linked  Identifiers  must  be  encoded  in 
a four  (4)  octet  integer. 

18.6.4.2  Version 

Version  2 (only)  is  supported. 

18.6.4.3  Linked  Reply  Values 

Responder  must  send  a linked  reply  value  that  corresponds  to 
the  original  invoke  operation  value. 

18.6.4.4  Error  Codes 

Responder  must  send  error  types  that  correspond  to  the 
operation  definition  for  the  original  invoke. 

18.6.5 Seirv7ices  Required  by  CMIP 
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CHIP  requires  the  services  provided  by  ACSE  and  ROSE.  The 
conformance  requirements  for  these  services,  and  the  underlying 
communication  required  to  support  them,  are  specified  in  section 
5.12.1.5. 

Editor's  Note:  Proposed  text  for  the  ULSIG  section  5.12.1.5.  No 
agreements  beyond  the  standards  are  made  except 
where  noted. 

5.12.1.5  Network  Management 
ROSE  Requirements : 

The  ROSE  requirements  are  as  specified 
in  ISO  9596  section  5.2:  Underlying 
Services,  and  section  6.2  Remote 
Operations . 

Operations  Classes 

o 1,2,  and  5 

Association  Classes 

o 3 

ACSE  Requirements: 
all 

Editor's  Note:  All  means  what  is 

specified  in  the  Stable 
OIW  agreements  for  ACSE 
in  section  5.5. 

Application  Contexts: 

o as  defined  by  ISO/DP  10040 

ANNEX  A 

Editor's  Note:  Pending  a DIS 
Version  of  the 
Standard.  This 
is  beyond  the 
standard. 


Abstract  Syntaxes 
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o { joint-iso-ccitt(2) 

association-control (2) 
abstract-syntax(l)  apdus(O) 
versionl(l) ) 

Editor's  Note:  ISSUE  - Will 
there  be  a 
verslon2(2) 
syntax  when  the 
addendum  on 
authentication 
becomes  a 
standard? 

Associated  Transfer  Syntax: 

o {joint- iso-ccitt(2) 
asnl(l)  basic-encod- 
ing(l))  "Basic 
Encoding  of  a single 
ASN.l  Type" 

o { joint-iso-ccitt  ms(9)  cmip(l) 
version2(2)  abstractSyntax(4) ) 

Editor's  Note:  Pending 

approval  of  the 
CMIP  Addendum, 
the  version2(2) 
is  beyond  the 
current  DIS 
standard.  As 
per  ISO/IEC 
9596  section 
7.5,  this 
abstract  syntax 
incudes  "all 
data  types 
resolved  by  the 
ANY  DEFINED  BY 
X productions, 
in  which  X is 
of  type  OBJECT 
IDENTIFIER." 

Associated  Transfer  Syntax: 
o {joint-iso-ccitt 
asnl(l) 

basic-encoding(l) ) 
"Basic  Encoding  of  a 
single  ASN.l  Type" 
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Mode -Select ion 

o Normal  Mode 

Presentation  Requirements: 

Presentation  Functional  Units: 

o kernel 

Presentation  Contexts 

o at  least  two  presentation 

contexts  must  be  supported 

Mode -Selection 

o Normal  mode  (non-X.410)  shall 

be  supported. 

Session  Requirements 

Session  Functional  Units 

o kernel 

o full  duplex 

Version  Number:  2 

Maximum  Size  of  User  Data  Parameter 
field:  Shall  be  10,240  octets. 

Implementations  may  specify  in  their 
PICS  a maximum  size  down  to  1024  octets 

Editor's  Note:  This  is  beyond  the 
current  standard. 


ASN.l  Encoding  Rules 

Some  INTEGER  types  of  the  CMIP  PCI  may 
exceed  the  maximum  size  specified  in  the 
UNIVERSAL  ASN.l  ENCODING  RULES,  section 
5.10.  See  the  range  of  values  for 
INTEGER  tjqje  Parameters  in  the  Network 
Management  chapter. 

Editor's  Note:  For  example:  a 32  bit 
unsigned  integer,  as 
specified  for  IEEE  802.x 
management  statistics. 
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can  represent  2**32- 1. 
This  would  require  5 
octets  for  ASN.l 
encoding.  The  current  4 
octet  restriction  in  the 
OIW  ASN.l  agreements  only 
allows  integers  up  to 
2**31 -1.  Specific 
agreements  are  needed  in 
section  18.6  regarding 
the  length  of  INTEGERS . 


18,7  MANAGEMENT  INFORMATION 


This  section,  which  is  based  on  ISO  standards'  documents  [MIM]  and 
[GDMO] , deals  with  basic  concepts  and  modelling  techniques  related  to 
management  information.  It  discusses  (i)  the  information  model  (sec. 
18.7.1),  (ii)  principles  for  naming  managed  objects  and  their 
attributes  (sec.  18.7.2),  and  (iii)  guidelines  for  defining  management 
information  (sec.  18.7.3).  It  is  not  within  the  scope  of  this 
section  to  define  specific  elements  of  management  iiiformation  - such 
definitions  can  be  obtained  via  the  Management  Information  Library 
(MIL)  produced  by  the  OSI  MIB  Working  Group  ( a subgroup  of  the  NMSIG 
). 

Editor's  Note:  Tutorial  Material:  Management  information  comprises 

all  information  in  the  network  that  is  of  interest  to 
network  management.  A computer  node  in  a network,  a 
transport  connection,  an  event  log  are  all  examples  of 
network  resources  for  which  management  information  can 
be  defined.  Management  information  is  collectively 
referred  to  as  the  MIB  or  Management  Information  Base. 

18.7.1  The  Information  Model 


This  subsection  contains  agreements  related  to  the  information 
model  as  specified  in  clause  5 of  [MIM] . 

Editor's  Note:  Tutorial  Material;  Management  information  is 
modelled  using  object-oriented  techniques.  All 
"things"  in  the  network  that  are  to  be  managed, 
are  represented  in  terms  of  managed  objects.  A 
managed  object  is  an  abstraction  (or  a logical 
view)  of  a "manageable"  physical  or  logical 
network  resource.  "Manageable,"  in  this  context, 
means  that  the  particular  resource  can  be  managed 
by  using  OSI  Management  Ser^/ices  and  Protocols. 
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Examples  of  managed  objects  include  protocol 
layer  entities,  modems,  connections,  etc. 

Each  managed  object  belongs  to  a particular  object 
class.  An  object  class  represents  a collection  of 
managed  objects  with  the  same,  or  similar 
properties.  Each  object  class  has  a pre-defined 
identifier  assigned  to  it  by  a standards' 
registration  authority.  A particular  managed 
object  existing  in  a particular  network  can  be 
regarded  as  an  instance  of  the  object  class  to 
which  it  belongs.  Thus,  an  object  instance 
represents  an  actual  realisation  of  an  object 
class.  A managed  object  is  identified  by 
specifying  its  object  class  and  object  instance. 

Managed  objects  contain  properties  which  are 
referred  to  as  attributes. 

Managed  objects  participate  in  relationships  with 
each  other.  The  relationships  that  are  of 
particular  concern  to  the  Management  Information 
Model  are  a)  the  containment  relationship,  and  b) 
the  inheritance  relationship.  These  relationships 
are  used  to  construct  management  information 
hierarchies,  as  described  below.  Managed  objects 
do  participate  in  relationships  other  than  the  two 
mentioned  above;  e.g.  the  Service  relationship, 
where  a managed  object  uses  the  services  provided 
by  another  managed  object,  as  in  the  case  of  a 
Transport  Layer  object  using  the  services  provided 
by  a Network  Layer  object.  These  relationships, 
however,  are  not  particularly  significant  for  the 
Information  Model.  They  can  be  easily  represented 
as  either  managed  objects  or  attributes,  contained 
within  the  managed  objects  participating  in  the 
relationship . 

MANAGEMENT  INFORMATION  HIERARCHIES 

The  following  Management  Information  Hierarchies 
are  identified: 

THE  CONTAINMENT  HIERARCHY 

This  hierarchy  is  constructed  by  applying  the 
relationship  "is  contained  in"  to  objects  and 
attributes.  Objects  of  one  class  may  contain 
objects  of  the  same  or  different  class. 

Attributes  are  contained  within  objects  at  any 
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level  of  the  containment  hierarchy.  Attributes 
cannot  contain  objects  or  other  attributes.  All 
object  classes  must  have  at  least  one  possible 
superior  in  the  containment  tree.  The  definition 
of  a class  may  permit  it  to  have  more  than  one 
such  superior.  However,  individual  instances  of 
such  a class  are  nevertheless  contained  in  only 
one  instance  of  a possible  containing  class.  A 
special  object  called  "root"  is  the  ultimate 
superior  in  the  containment  hierarchy. 

The  containment  hierarchy  is  important  because  it 
is  used  for  naming  object  instances.  It  also 
defines  an  existence  dependency  among  its 
components;  i.e.  an  object  or  attribute  can 
'exist'  only  if  the  containing  object  also 
'exists'.  If  an  object  contains  other  objects,  it 
cannot  be  deleted  until  the  contained  objects  have 
been  deleted.  The  contained  objects  may  be 
deleted  automatically,  if  this  is  specified  in  the 
definition  of  the  managed  object  class (es)  of  the 
contained  objects. 

THE  INHERITANCE  OR  OBJECT  CLASS  HIERARCHY 

This  hierarchy  is  constructed  by  applying  the 
relationship  "inherits  properties  of"  to  object 
classes.  An  object  class  may  inherit  properties 
of  another  object  class,  with  refinement  obtained 
by  adding  additional  properties.  The  inheriting 
class  is  called  the  subclass  in  this 
relationship,  and  the  parent  the  superclass.  For 
example,  the  class  "Network  Entity"  may  be  a 
subclass  of  "Layer  Entity"  and  a superclass  of 
"X.25  Network  Entity."  Each  class  may  have  zero, 
one  or  more  subclasses.  Subclasses  may  in  turn 
have  furthur  subclasses,  to  any  degree.  A special 
object  called  "top"  is  the  ultimate  superclass. 

The  inheritance  hierarchy  is  useful  in  that  it 
leads  to  a manageable  and  extensible  technique  for 
the  definition  of  object  classes.  The  inheritance 
hierarchy  has  NO  relevance  to  object  and/or 
instance  naming. 

THE  REGISTRATION  HIERARCHY 

This  hierarchy  is  not  based  on  any  particular 
relationship,  and  is  independent  of  both  the 
inheritance  and  containment  hierarchies.  It 
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contains  Object  Identifiers  for  object  classes  and 
attributes,  as  assigned  by  the  standards' 
registration  authority. 

The  registration  hierarchy  is  important  because  it 
is  used  for  identifying  object  classes  and 
attributes.  It  is  used  to  ensure  global 
uniqueness  and  to  permit  extensions  without  a 
centralized  registration  authority. 


18.7.1.1  Basic  Concepts 

The  following  concepts/features  of  the  information  model  are 
supported,  as  specified  in  clause  5 of  [MIM] . 


manage d ob j e c t 
attribute 
attribute  value 


managed  object  class 
group  attribute 
assertion 


managed  object 

instance 

set-valued 

attribute 

management 

operation 


encapsulation  behaviour 


notification 


18.7.1.2  Management  Operations  Supported 

The  following  management  operations  are  supported,  as 

specified  in  clause  5.2  of  [MIM]. 

Operations  that  apply  to  attributes  : 

Get  attribute  value 
Replace  attribute  value 
Set-to-default  value 
Add  attribute  value 
Remove  attribute  value 

Operations  that  apply  to  managed  objects  : 

Create 

Delete 

Action 


18.7.1.3  Filter 
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The  concept  of  filter  is  supported  as  specified  in  clause 
5.3  of  [MIM] . Restrictions  on  its  usage  are  specified  in 
section  18.6.2.2.2  of  these  agreements. 


18.7.1.4  Inheritance 

All  the  inheritance  related  concepts  (refinement,  subclass, 
superclass,  inheritance  hierarchy,  etc)  presented  in  clause 
5.5  of  [MIM]  are  supported. 

The  following  additional  constraints  need  to  be  enforced  for 
the  Phase  1 lAs  in  order  to  remove  potential  ambiguities: 

Subclasses  must  inherit  ALL  the  optional  attributes  of  their 
respective  superclasses.  Once  inherited,  these  attributes 
may  remain  as  optional  attributes  of  the  subclass  or  may 
become  mandatory  attributes  of  the  subclass. 

When  an  instance  of  a managed  object  class  is  created,  it 
must  support  all  the  mandatory  attributes  defined  for  that 
class.  The  instance  may  support  some  or  none  of  the 
optional  attributes  defined  for  its  class.  Once  created, 
the  managed  object  instance  must  support  , throughout  its 
lifetime,  exactly  the  same  set  of  attributes  that  were 
assigned  to  it  at  the  time  of  creation,  i.e.  dynamic 
creation/deletion  of  attributes  within  an  object  instance  is 
not  allowed. 

During  the  lifetime  of  a managed  object  instance,  each  of 
its  attributes  must  have  a value  that  is  valid  for  the 
attribute  syntax  of  that  attribute. 

The  range  of  the  attribute  values  for  any  attribute  may  not 
be  redefined  in  the  process  of  refinement.  If  it  is 
anticipated  that  the  range  of  attribute  values  may  change, 
then  the  use  of  the  ASN.l  enumerated  type  for  the  attribute 
syntax  is  discouraged. 

Multiple  inheritance  is  not  supported  for  the  Phase  1 lAs , 
since  no  requirements  for  it  have  been  voiced  within  the 
NMSIG. 


18.7.1.5  Polymorphism 
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Editor's  Note:  Polymorphism  is  a very  useful  concept  insofar 
as  it  facilitates  interoperability  across 
different  versions  and  vendor  extensions  of  a 
managed  object  class.  However,  issues  and 
problems  related  to  it,  especially  those 
dealing  with  the  naming  of  polymorphic 
classes,  have  not  been  thoroughly  examined  or 
resolved  in  the  standards.  Given  this,  does 
NMSIG  feel  the  need  to  incorporate 
polymorphism  into  the  Phase  1 lAs  ? 

Polymorphism  is  not  supported  for  the  Phase  1 lAs , since  no 
requirements  for  it  have  been  voiced  within  the  NMSIG. 


18.7.2 Principles  of  Naming 

This  subsection  contains  agreements  about  principles  of  naming  as 
specified  in  clause  6 of  [MIM] . 


18.7.2.1  Containment  Hierarchy 

All  concepts  about  the  containment  hierarchy  presented  in 
clause  6.1  of  [MIM]  are  supported. 


18.7.2.2  Name  Structure 


18.7.2.2.1 Object  Class  Identification 

A managed  object  class  is  identified  by  an  ASN.l  object 
identifier,  as  specified  in  clause  6.2.1  of  [MIM]. 


18.7.2.2.2  Object  Instance  Identification 

The  distinguished  name  approach  is  supported  for  the 

Identification  of  managed  object  instances. 

Editor's  Note:  Many  issues/questions  regarding  the 
naming  of  managed  object  instances  have 
arisen  because  the  related  standards' 
text  (clause  6.2.2  of  [MIM])  is  somewhat 
unclear . 
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The  following  issues  related  to  naming 
managed  object  instances  are  identified 


a)  Referring  to  the  first 

sentence  of  clause  6,2.2  of 
[MIM] , which  starts  with  "The 
definition  of  each  managed 
object  class  does  "an" 

identification  attribute  imply 
"only  one"  or  "at  least  one"  ? 
Can  different  name  bindings 
for  the  same  managed  object 
class  specify  different 
distinguishing  attributes,  or 
is  there  just  one 
distinguishing  attribute  per 
managed  object  class  ? 

b)  Do  name  bindings  get  inherited 
? 

c)  Is  the  distinguishing 
attribute  of  a subclass  the 
same  or  different  from 
distinguishing  attribute  of 
its  superclass?  If  the 
superclass  and  its  subclass 
have  the  same  distinguishing 
attribute,  there  could  be 
ambiguities  in  situations 
where  instances  of  both  the 
superclass  and  its  subclass 
exist  in  the  containment  tree. 
If  the  superclass  and  its 
subclass  do  not  have  the  same 
distinguishing  attribute, 
polymorphism  cannot  be 
supported, 

d)  What  is  the  point  of  reference 
from  which  managed  object 
instances  are  defined  - full 
distinguished  name  or  partial 
distinguished  name? 


18.7.2.2.3  Selection  Of  Distinguishing  Attributes 
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The  distinguishing  attribute  for  a managed  object  class 
must  be  very  carefully  selected.  It  must  be  able  to 
distinguish  not  only  between  instances  of  the  object 
class  for  which  it  is  defined,  but  also  between 
instances  of  ail  other  object  classes  that  have  the 
same  superior  object  class.  For  example,  consider  the 
following  figure  which  shows  the  structure  of  a 
containment  tree  : 


A 

/ \ 

/ \ 

B C 

/ 

/ 

C 

Here,  A represents  instances  of  Object  Class  A,  B 
represents  Instances  of  Object  Glass  B and  C represents 
instances  of  Object  Class  C.  As  can  be  seen  from  the 
figure,  instances  of  Object  Class  C may  be  contained  in 
either  instances  of  Object  Class  A,  or  in  instances  of 
Object  Class  B.  When  the  RDN  of  Object  Class  C is 
defined,  it  is  necessary  to  make  sure  that  it  is 
different  from  the  RDN  for  Object  Class  B.  If  Object 
Class  B and  Object  Class  C were  to  support  the  same 
RDN,  it  would  not  be  possible  to  unambiguously  traverse 
down  the  containment  tree  from  A. 

The  above  example  shows  a simple  containment  tree.  In 
the  real  world,  however,  containment  trees  could  be 
much  more  complex,  and  the  selection  of  distinguishing 
attributes  could  involve  extensive  checking  and 
verification  over  multiple  object  classes. 

Editor's  Note:  Consider  the  following  proposal  : 

"The  process  of  selecting  the  correct 

distinguishing  attribute  can  be  made  simpler  if 
every  object  class  supports  an  additional 

distinguishing  attribute  called  "My  Object  Class," 
whose  value  identifies  the  object  class  it  is 
contained  in.  If  this  is  done,  the  process  of 
selecting  and  verifying  the  RDN  of  an  object  class 
would  not  require  the  consideration  of  object 
classes  other  than  the  one  defining  the  RDN." 

The  above  proposal  will  be  worked  on  by  the  NMSIG  and 
submitted  to  the  standards. 
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18.7.2.2.4 Attribute  Identification 


Each  individual  attribute  of  a managed  object  is 
identified  by  an  ASN.l  object  identifier,  as  specified 
in  clause  6.2.4  of  [SMI  Part  1]. 


18.7.3 Guidelines  for  the  Definition  of  Management  Information 

This  subsection  contains  agreements  about  guidelines  for  the 
definition  of  management  information,  as  specified  in  [GDMO] . 
These  guidelines  form  a normative  part  of  the  standard;  hence 
they  must  be  strictly  followed  while  defining  management 
information. 


18.7.3.1  Syntactical  Definitions  of  Management  Information 

18.7.3.1.1 Managed  Object  Class  Template 

For  Phase  1 lAs , the  template  supported  by  NMSIG  for 
defining  managed  object  classes  is  the  same  as  the 
Managed  Object  Class  template  defined  in  clause  10.3.2 
of  [GDMO] , with  the  agreement  that  the  optional  clause 
POLYMORPHIC  SET  is  not  to  be  used.  The  POLYMORPHIC  SET 
clause  is  not  supported,  as  per  the  agreements  on 
polymorphism  specified  in  18.7.1.5. 

Supporting  productions  for  "propertylist"  and 
"modifier"  are  adopted  as  specified  in  clause  10.3.2  of 
[GDMO] . 

Supporting  definitions  of  the  DERIVED  FROM,  POLYMORPHIC 
SET,  ATTRIBUTES,  GROUP  ATTRIBUTES,  CREATE,  DELETE, 
ACTIONS,  NOTIFICATIONS,  and  PACKAGE  clauses  of  the 
managed  object  class  template  are  adopted  as  defined  in 
clause  10.3.3  of  [GDMO]  with  the  following  exceptions: 

The  <specific-error-label>  shall  not  be  used 
because  the  managed  object  class  template  allows 
for  multiple  specific  errors  to  be  defined  within 
an  object  class,  and  it  is  not  possible  to 
unambiguously  communicate  over  CMIP  multiple 
specific  errors  pertaining  to  a single  managed 
object  class. 
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For  the  GROUP  ATTRIBUTES  clause,  new  attributes 
shall  not  be  added  to  the  group  attribute  from 
within  the  managed  object  class  template  because 
this  can  lead  to  ambiguities.  Hence,  the 
[<attribute-label>]  portion  of  the  supporting 
definition  for  the  GROUP  ATTRIBUTE  clause  shall 
not  be  used. 

For  the  PACKAGE  clause  the  <condition-def inition> 
shall  only  reflect  the  capabilities  of  the 
underlying  resource  that  the  managed  object  class 
is  representing. 


18.7.3.1.2  Conditional  Package  Template 

The  CONDITIONAL  PACKAGE  template  specified  in  clause 
10.4  of  [GDMO]  is  supported.  The  agreements  listed  in 
18,7.3.1.1  for  the  supporting  definitions  of  the 
MANAGED  OBJECT  CLASS  template  are  to  be  applied  to  the 
CONDITIONAL  PACKAGE  template,  too. 

18.7.3.1.3  Specific  Error  Template 

The  SPECIFIC  ERROR  template  is  not  supported  for  the 
reasons  given  in  18.7.3,1.1 


18.7.3.1.4  Name  Binding  Template 

The  NAME  BINDING  template  is  supported  as  described  in 
clause  10.6  of  [GDMO]  except  that  the  CONSTRAINTS 
clause  shall  not  be  used  because  its  usage  has  not  been 
clearly  specified  in  the  standard. 


18.7.3.1.5 Attribute  Template 

The  ATTRIBUTE  template  described  in  clause  10.7  of 
[GDMO]  is  supported.  The  DERIVED  FROM  and  PERMITTED 
VALUES  clauses  of  the  ATTRIBUTE  template  are  not 
supported,  in  general,  because  their  usage  could  lead 
to  major  ambiguities.  However,  usage  of  attributes 
defined  in  [DMI]  that  use  the  DERIVED  FROM  clause  and 
are  registered  is  allowed.  The  PERMITTED  VALUES  clause 
can  only  be  used  if  the  ATTRIBUTE  SYNTAX  has  been 
previously  defined;  e.g.,  in  [DMI],  The  REGISTERED  AS 
clause,  which  has  been  defined  as  optional,  is  made 
mandatory.  The  BEHAVIOUR  clause  is  made  mandatory. 
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18.7.3.1.6 Group  Attribute  Template 

The  GROUP  ATTRIBUTE  template  is  supported  as  described 
in  clause  10.8  of  [GDMO] . 


18.7.3.1.7  Action  Template 

The  ACTION  template  is  supported  as  described  in  clause 
10.10  of  [GDMO] . 

18.7.3.1.8  Notification  Template 

The  NOTIFICATION  template  is  supported  as  described  in 
clause  10.11  of  [GDMO]. 


18.7.3.2  Guidelines  For  Defining  Behaviour 

The  following  details  should  be  provided  in  the  definition 
of  each  managed  object  class  : 

a textual  description  of  the  network  resource  it 
represents,  including  its  functional  role. 

a description  of  the  relationships  that  instances 
of  this  managed  object  class  participate  in  with 
instances  of  the  same  or  other  managed  object 
classes . 

a description  of  the  operations  that  are  supported 
by  it,  with  precise  definition  of  the  effects, 
side  effects  if  any,  constraints,  response 
notifications,  failure  modes,  etc. 

specification  of  how  instances  of  this  managed 
object  class  are  created  and  deleted,  particularly 
whether  they  can  be  created/deleted  via  the 
management  CREATE/DELETE  operations . 

a description  of  notifications  that  can  be 
generated,  the  conditions  that  generate  them 
(e.g.,  crossing  of  a threshold),  their  contents 
and  side-effects,  if  any.  In  particular,  identify 
all  the  attributes  that  are  subject  to  the 
AttributeChange  and  StateChange  notifications,  if 
these  notifications  are  supported. 
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other  constraints,  including  those  involving  other 
managed  object  classes. 


18.7.3.3  Other  Guidelines 


The  Systems  Management  functions  have  defined  various 
attributes  and  events,  as  indicated  in  section  18.5  of  these 
agreements.  Object  Definers  are  encouraged  to  make  use  of 
these  attributes  and  events  wherever  applicable. 
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APPENDIX  A 


--  MANAGEMENT  INFORMATION  LIBRARY  (MIL^ 
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MANAGEMENT  INFORMATION  LIBRARY 
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Version  4.0 

March  29,  1990 
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A.l.  INTRODUCTION 

This  document  is  produced  by  the  OSI  MIB  Working  Group  (a  subgroup  of  the 
NMSIG) . It  provides  definitions  of  management  information  - managed 
object  classes,  name  bindings,  attributes,  actions  and  notifications. 
Provision  of  these  definitions  is  made  by:  a)  references  to  standards' 
documents  that  contain  these  definitions,  or  b)  inclusion  of  the  actual 
definitions  in  this  document;  in  which  case  they  will  be  registered  in 
the  NMSIG  arc  of  the  ISO  ASN.l  Object  Identifier  Tree. 

Management  information  definitions  provided  by  the  OSI  MIB  Working  Group 
have  been  introduced  to  accelerate  the  process  of  defining  management 
information.  They  are  intended  to  be  implementable  but  also  serve  as  a 
basis  from  which  other  implementations  may  define  refinements  or 
alternatives.  These  definitions  do  not  override  those  provided  by 
standards'  groups  or  other  OIW  SIGs. 

Editor's  Note:  The  intention  is  to  progress  these  definitions  to  an 
International  Management  Information  Library. 
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A. 2.  RULES  AND  PROCEDURES 

The  following  rules  and  procedures  apply  to  managed  object  class 
definitions  that  are  to  be  included  in  the  MIL  : 


(i) 

All  managed  object  class  definitions  provided  by  the  MIL  must 
comply  with  the  NMSIG  (ISO)  object  templates. 

(ii) 

A managed  object  class  definition  provided  by  the  MIL  must 
represent  an  abstraction  of  an  identifiable  logical  or  physical 
resource  that  can  be  managed  via  OSI  management. 

(iii) 

All  managed  object  classes  in  the  MIL  will  have  registered  ASN.l 
object  identifiers  assigned  either  by  a standards'  body  if  it  is 
defining  the  managed  object  class,  or,  if  the  managed  object 
class  definition  is  being  progressed  within  the  NMSIG,  by  the 
NMSIG  in  its  branch  of  the  ISO  Registration  Tree. 

(iv) 

A managed  object  class  will  be  selected  as  a candidate  for 
inclusion  into  the  MIL  if  there  are  at  least  two  NMSIG  members 
from  different  companies  who  express  a requirement  (strong 
interest)  for  the  managed  object  class.  If  this  is  not  a 
standards'  de'^ined  managed  object  class,  then  there  must  be  at 
least  one  NMSIG  member  who  is  committed  to  developing  the 
definition  of  the  managed  object  class. 

(V) 

A managed  object  class  selected  for  the  MIL  will  be  given  a 
priority  based  on  the  n»amber  of  members  who  express  interest  in 
it . 

(vi) 

All  managed  object  class  definitions  that  are  proposed  for 
inclusion  into  the  MIL  will  undergo  a review  process  within  the 
NMSIG.  NMSIG  member  defined  managed  object  classs  will 
additionally  undergo  a ballotting  process.  If  problems  are  found 
with  a standards'  defined  managed  object  class,  the  appropriate 
standards'  body  will  be  approached.  If  problems  are  found  with  a 
member  defined  managed  object  class,  it  will  be  returned  with 
comments . 

(vii) 

Based  on  its  priority,  there  will  be  a call  for  contributions  on 
the  definition  of  a managed  object  class  at  an  NMSIG  meeting. 
Contributions  could  be  in  the  form  of:  a)  identification  of  a 
standards'  body  that  is  currently  working  on  the  definition,  or 
b)  an  NMSIG  member  definition  of  the  managed  object  class. 

(viii) 

There  will  be  no  obsolescence  of  any  managed  object  class 
specified  in  the  MIL. 
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A. 3.  GENERAL  GUIDELINES 

It  is  recofljinended  that  the  following  guidelines  be  used  in  general  for 
all  managed  object  definitions,  unless  there  is  a specific  exception 
condition: 

a)  For  the  ObjectCreation  Notification,  send  all  the  attributes  of  the 
created  managed  object  instance  in  the  Createinfo  field. 
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A. 4.  OBJECT  CLASSES 


A . 4 . 1 . Discriminator 

This  managed  object  class  is  used  to  define  the  criteria  for  controlling 
management  services.  Refer  to  [ISO  Doc  x]  for  the  definition  of  this 
managed  object  class. 


A. 4. 2.  Event  Forwarding  Discriminator 

This  managed  object  class  is  used  to  define  the  criteria  that  must  be 
satisfied  by  potential  event  reports  before  the  event  reports  are 
forwarded  to  a particular  destination.  Refer  to  [ISO  Doc  x]  for  the 
definition  of  this  managed  object  class. 


A.  4. 3.  KMSIG  Agent 

A o 4 . 3 . 1 . NMSIG  Agent  Definition 

nmsig- agent  MANAGED  OBJECT  CLASS 

DERIVED  FROM  { top } 

CHARACTERISED  BY 

BEHAVIOUR  DEFINITIONS  agent-behaviour 
ATTRIBUTES  nmsig- agentid  GET, 

REGISTERED  AS  {obj -class} 

A . 4 . 3 . 2 . NMSIG  Agent  Behaviour 

agent -behaviour  BEHA^VIOUR 

DEFINED  AS 

This  managed  object  class  represents  an  NMSIG  agent  system,  which 
is  an  open  system  that  supports  the  NMSIG  agreements  to  make  one 
or  more  managed  objects  visible  to  other  open  systems  that 
support  the  NMSIG  agreements. 

An  NMSIG  agent  system  may  not  support  more  than  one  instances  of 
the  NMSIG  Agent  managed  object  class.  If  supported,  this 
instance  is  assumed  to  be  pre-existent  when  the  NMSIG  agent 
system  comes  up;  i.e.,  management  CREATE  or  DELETE  is  not 
supported. 

At  this  time,  the  NMSIG  Agent  managed  object  class  only  serves  to 
name  management  support  managed  objects  (e.g., 
EventForwardingDiscriminator) . 
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A. 4. 4.  NMSIG  Computer  System 

Editor's  Note:  A model  has  been  proposed  for  defining  managed  object 

classes  related  to  computers,  as  follows: 

The  philosophy  behind  the  proposed  model  is  to  define  a 
composite  or  aggregrate  managed  object  class  called 
"computerSystem"  that  provides  a high  level  view  of  a 
computer  system,  including  its  physical  and  logical,  as 
well  as  its  hardware  and  software  components.  Detailed 
views  of  these  components  are  then  modelled  as  object 
classes  contained  within  the  computerSystem  object 
class,  as  shown  in  the  CONTAINMENT  TREE  below.  (NOTE  : 
This  is  NOT  an  inheritance  tree.) 

computerSystem 


tapeDrive  | printer  j | j applicationX  

discDrive  processing  j os 

Entity  j 

I 

coTransportProtocolLayerEntity 

I 

transportConnection 

A great  benefit  provided  by  this  model  is  flexibility. 
As  and  v;hen  more  computer  components  need  to  be 
specified,  they  can  be  defined  as  individual  object 
classes  and  "plugged"  into  the  above  structure  under 
computerSystem,  without  upsetting  the  other  object 
classes . 

The  'system'  managed  object  class  defined  in  [DMI]  was 
not  used  because  it's  definition  was  considered  to  be 
inappropriate . 


A.4.4.1.  NMSIG  Computer  System  Definition 

nmsig-computerSystem  MANAGED  OBJECT  CLASS 
DERIVED  FROM  { top ) 

CHARACTERISED  BY 

BEHAVIOUR  DEFINITIONS  computerSystem-behaviour 
ATTRIBUTES  nmsig-systerald  GET, 

AdministrativeState  GET-REPLACE 
HealthState  GET, 
OperationalState  GET, 
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nmsig-systemTime  GET, 

nmsig-peripheralNames  GET, 
nmsig-userFriendlyLabel  GET-REPLACE 
NOTIFICATIONS  Obj  ectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed, 

AttributeChangeUnConf irmed, 

StateChangeUnConf irmed. 

Process ingErrorAlarmUnConf irmed, 
EnvirorunentalAlarmUnConf  irmed, 
EquipmentAlarmUnConf irmed 

REGISTERED  AS  {obj -class} 

A. 4. 4. 2.  NMSIG  Computer  System  Behaviour 
computerSystem-behaviour  BEHAVIOUR 
DEFINED  AS 

The  nmsig-computerSystem  managed  object  class  is  a composite  or 
aggregate  object  class  that  provides  a high  level  view  of  a 
general  purpose  business  computer  system,  including  its  physical, 
logical,  hardware  and  software  components. 

The  Computer  System  managed  object  class  supports  all  the  values 
of  the  administrative  state.  It  supports  only  the  'enabled'  and 
'disabled'  values  of  the  operational  state. 

The  'enabled'  value  of  the  operational  state  indicates  that  the 
underlying  computer  system  resources  are  together  capable  of 
providing  minimal  computing  services.  These  enabled  resources 
may  or  may  not  be  modelled  as  managed  objects,  and  may  or  may  not 
include  the  entire  set  of  resources  which  together  are  viewed  as 
the  computer  system. 

The  'disabled'  value  of  the  operational  state  indicates  that  the 
underlying  computer  system  resources  are  incapable  of  providing 
minimal  services  at  the  current  time. 

The  peripheralNames  attribute  specifies  the  names  of  auxiliary 
devices  that  are  used  by  the  underlying  computer  system  resource. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  computer  sytera 
instance . 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall  be 
NULL. 
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Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-peripheralNames , nmsig-userFriendlyLabel , 

HealthState . 

Attributes  that  are  subject  to  the  StateChange  notification  are: 
AdministrativeState  and  OperationalState . 

A. 4. 5.  NMSIG  Connection  Oriented  Tranport  Protocol  Layer  Entity 

A. 4. 5.1.  NMSIG  CO  Transport  Protocol  Layer  Entity  Definition 


nmsig-coTransportProtocolLayerEntity  MANAGED  OBJECT  CIASS 


DERIVED  FROM 
CHARACTERIZED  BY 
BEHAVIOUR  DEFINITIONS 
ATTRIBUTES 


NOTIFICATIONS 


{top} 

coTransportPro toco ILayerEntity -behaviour 
nmsig-coTransportProtocoLLayerEntityld  GET , 
AdministrativeState  GET-REPLACE, 
OperationalState  GET, 

HealthState  GET, 

nms ig- localTransportAddresses  GET , 
nmsig-maxConnections  GET, 
nms ig-openConnect ions  GET, 

Outgo ingConnec  t ionsReque  s t Counter  GET , 
IncomingConnectionsRequestCounter  GET , 

Outgo ingConnec tionRej  ectErrorCounter  GET , 
IncomingConnec tionRej  ectErrorCounter  GET , 
Outgo ingDisconnectErrorCounter  GET , 
IncomingDisconnectErrorCounter  GET , 
nrasig- incomingNormalDisconnectCounter  GET , 
nmsig-outgoingNormalDisconnectCounter  GET , 
OctetsSentCounter  GET, 
OctetsReceivedCounter  GET, 
IncomingTemporalErrorCounter  GET , 
OutgoingTemporalErrorCounter  GET , 
nmsig-checksumTPDUsDiscardedCounter  GET , 
nmsig- transportEntityType  GET, 
nmsig-productinfo  GET, 
nmsig-entityUpTime  GET 
Obj  ectCreationUnConf irmed, 
ObjectDeletionUnConf irmed, 
AttributeChangeUnConf irmed , 

S tateChangeUnConf irmed , 
ProcessingErrorAlarmUnConf irmed, 
nms ig- counterWrapUnConf irmed 


REGISTERED  AS  (obj -class} 

A. 4. 5. 2.  NMSIG  CO  Transport  Protocol  Layer  Entity  Behaviour 
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coTransportProtocolLayerEntity-behaviour  BEHAVIOUR 
DEFINED  AS 

The  managed  object  class  nmsig-coTransportProtocolLayerEntity 
represents  an  instantiation  of  any  connection-oriented  transport 
layer  protocol  e.g.  the  ISO  Transport  Protocol  layer  or  the 
Internet  Transmission  Control  Protocol  (TCP) . The  transport 
protocol  layer  is  layer  four  of  the  OSI  Reference  model.  It 
provides  for  the  transparent  transference  of  data  between  two 
peer  entities.  It  relieves  its  users  from  any  concerns  about  the 
detailed  way  in  which  supporting  communication  media  are  utilized 
to  achieve  this  transfer.  The  connection  oriented  transport 
protocol  layer  entity  makes  use  of  a transport  connection  for  the 
purpose  of  transferring  data. 

This  managed  object  class  represents  a "generic"  view  of  a 
connection  oriented  transport  protocol  layer  entity.  It  does  not 
concern  itself  with  the  details  of  specific  transport  protocols 
like  ISO  TP  or  TCP.  Transport  entitles  that  are  tied  to  a 
specific  protocol  can  be  defined  as  its  subclasses;  in  fact  their 
definitions  are  being  progressed  within  various  standards' 
bodies.  The  purpose  of  defining  this  managed  object  class, 
however,  is  to  provide  a common  base  that  will  facilitate  the 
high  level  management  of  similar  but  slightly  differing 
resources . 

The  connection  oriented  transport  protocol  layer  entity  supports 
all  values  of  the  administrative  and  operational  states. 

The  'enabled'  value  of  the  operational  state  indicates  that  the 
underlying  transport  protocol  layer  entity  resource  is  capable  of 
supporting  transport  connections  but  currently  has  no  open 
transport  connections. 

The  'disabled'  value  of  the  operational  state  indicates  that  the 
underlying  transport  protocol  layer  entity  resource  is  not 
capable  of  supporting  any  transport  connections. 

The  'active'  value  of  the  operational  state  indicates  that  the 
underlying  transport  protocol  layer  entity  resource  is  currently 
supporting  at  least  one  transport  connections  and  is  capable  of 
supporting  additional  transport  connections . 

The  'busy'  value  of  the  operational  state  indicates  that  the 
underlying  transport  protocol  layer  entity  resource  is  supporting 
the  maximum  momber  of  transport  connections  that  it  is  capable  of 
supporting. 
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The  Createinfo  field  of  the  ObjectCreation  notification  shall 
contain  all  the  attributes  of  the  created  connection-oriented 
transport  protocol  layer  entity  instance. 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  connection-oriented 
transport  protocol  layer  entity  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-localTransportAddresses , niEsig-maxConnections , nmsig- 
productlnfo,  HealthState. 

Attributes  that  are  subject  to  the  StateChange  notification  are: 
AdministrativeState  and  OperationalState . 

The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 


A. 4. 6.  NMSIG  Connectionless  Network  Protocol  Layer  Entity 

A. 4. 6.1.  NMSIG  Connectionless  Network  Protocol  Layer  Entity 

Definition 

nmsig-clNetworkProtocolLayerEntity  MANAGED  OBJECT  CLASS 

DERIVED  FROM  { top ) 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  clNetworkProtocolLayerEntity-behavlour 
ATTRIBUTES  nmsig-clNetworkProtocolLayerEntityld  GET, 

AdministrativeState  GET-REPLACE, 
OperationalState  GET, 

HealthState  GET, 

nmsig-localNetworkAddresses  GET, 
nmsig-nPDUTimeToLive  GET-REPLACE, 
PDUsSentCounter  GET, 

PDUsReceivedCounter  GET, 
nmsig-PDUsForwardedCounter  GET, 
nmsig-PDUsReasmbldOKCounter  GET, 
nmsig-PDUsReasmblFailCounter  GET , 
nmsig-PDUsDiscardedCounter  GET, 
nmsig-networkEntityType  GET, 
nmsig-productinfo  GET, 
nmsig-entityUpTlme  GET 

NOTIFICATIONS  ObjectCreationUnConf irmed, 

ObjectDeletionUnConf irmed. 

At tributeChangeUnConf irmed. 

Process ingAlarmUnConf irmed, 
StateChangeUnConf irmed , 
nmsig-counterWrapUnConf irmed 
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PACKAGE  runs ig-clNe two rkProtocolLayerEntityRedirect ion 

PRESENT  IF  connectionless  network  protocol  layer 

entity  supports  redirection  of  reed  PDUs 

REGISTERED  AS  {obj -class} 

Ao4.6.2.  !®1SIG  Cotmectionless  Metwork  Protocol  Layer  Entity 
Behaviour 

clNetworkPro toco ILayerEntity “behaviour  BEHAVIOUR 
DEFINED  AS 

The  managed  object  class  ransig-clNetworkProtocolEntity 
represents  an  instantiation  of  a connectionless  network 
protocol  layer.  The  network  layer  is  layer  three  of  the  OSI 
Reference  Model.  It  provides  network  services  for  the 
transparent  transfer  of  data  between  peer  transport  entities. 

It  relieves  the  transport  protocol  layer  from  the  need  to  know 
anything  about  the  underlying  network  technologies  used  to 
achieve  data  transfer.  The  connectionless  network  protocol 
layer  does  not  make  use  of  a network  connection  for  the 
purposes  of  transferring  data.  No  d5mamic  peer  to  peer 
agreement  is  involved  in  the  process  of  data  transfer. 

An  instance  of  this  managed  object  class  supports  only  one  type 
of  protocol  and  one  address  domain. 

This  managed  object  class  represents  a "generic"  view  of  a 
connectionless  network  protocol  laj'^er  entity.  It  does  not 
concern  itself  with  the  details  of  specific  network  protocols. 
Network  entities  that  are  tied  to  a specific  network  protocol 
can  be  defined  as  its  subclasses;  in  fact  their  definitions  are 
being  progressed  within  various  standards'  bodies.  The  purpose 
of  defining  this  maiiaged  object  class,  however,  Is  to  provide  a 
common  base  that  will  facilitate  the  high  level  management  of 
similar  but  slightly  differing  resources. 

The  NMSIG  connectionless  network  protocol  layer  entity  managed 
object  class  supports  all  the  values  of  the  administrative 
state  attribute.  It  supports  only  the  'disabled'  and  'enabled' 
values  of  the  operational  state  attribute. 

The  'enabled'  value  of  the  operational  state  Indicates  that  the 
underlying  connectionless  network  protocol  layer  entity 
resource  is  capable  of  providing  connectionless  network  layer 
services . 
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The  'disabled'  value  of  the  operational  state  indicates  that 
the  underlying  connectionless  network  protocol  layer  entity 
resource  is  incapable  of  supporting  any  network  services  at  the 
current  time. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  connectionless 
network  protocol  layer  entity  instance. 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  connectionless 
network  protocol  layer  entity  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are;  nmsig- localNetworkAddresses , nmsig-nPDUTimeToLive , nmsig- 
productlnfo,  and  Healths tate 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState . 

The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 

A. 4. 6. 3.  NMSIG  CL  Network  Protocol  Layer  Entity  Redirection  Package 

runs ig-clNetworkProtocolLayerEntityRedirect ion  CONDITIONAL  PACKAGE 

BEHAVIOUR  DEFINITIONS  clNetworkProtocolLayerEntityRedirection- 

behaviour 

ATTRIBUTES  nmsig-PDUsRedirected  GET 
REGISTERED  AS  {package} 

clNe two rkPro toco ILayerEntityRedirect ion-behaviour  BEHAVIOUR 
DEFINED  AS 

This  package  reflects  the  redirection  capability  of  the 
underlying  connectionless  network  protocol  layer  entity  resource. 


A . 4 . 7 . NMS IG  Equipment 

A. 4. 7.1.  NMSIG  Equipment  Definition 

nmsig- equipment  MANAGED  OBJECT  CLASS 
DERIVED  FROM  ( top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  equipment -behaviour 
ATTRIBUTES  nmsig-equipmentid  GET, 
OperationalState  GET, 
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HealthState  GET, 

AdministrativeState  GET-REPLACE, 

nmsig- locationName  GET-REPLACE, 

nmsig-contactNames  ADD-REMOVE, 

nmsig- equipmentPurpose  GET-REPLACE , 

nmsig-productinfo  GET, 

nmsig- vendorName  GET-REPLACE, 

nmsig-userFriendly Label  GET -REPLACE 

NOTIFICATIONS  EnvironmentalAlarmUnConf irmed , 

EquipmentAlarmUnConf irmed , 

Obj  ectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed. 

At  t r ibu teChangeUnConf i rme  d , 

StateChangeUnconf irmed 

REGISTERED  AS  {obj -class) 

A . 4 . 7 , 2 , NMSIG  Equipment  Behaviour 

equipment -behaviour  BEHAVIOUR 

DEFINED  AS 

The  NMSIG  equipment  managed  object  class  represents  physical 
entities.  Instances  of  this  managed  object  class  are  located 
in  specific  geographic  locations  and  support  some  type  of 
functions.  For  example,  a PBX,  which  may  be  regarded  as  an 
instance  of  this  managed  object  class,  performs  switching 
functions.  Multiplexers,  amplifiers,  and  repeaters  which  can 
also  be  regarded  as  instances  of  this  managed  object  class 
perform  transmission  functions.  Equipment  may  be  nested  in 
equipment,  thereby  creating  a containment  relationship.  For 
example,  a line  card  is  contained  in  an  equipment  shelf  which 
is  nested  in  a relay  rack  which  is  part  of  a switch. 

Instances  of  this  managed  object  class  may  be  endpoints  of  a 
circuit  or  facility. 

The  NMSIG  Contact  Names  attribute  specifies  who  (persons  or 
organizations)  are  to  be  contacted  about  the  equipment. 

The  NMSIG  Location  Name  attribute  identifies  where  the 
equipment  is  located. 

The  NMSIG  Vendor  Name  attribute  identifies  the  organization 
from  whom  the  equipment  was  obtained  (i.e.,  purchased,  leased, 
etc . ) . 
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The  NMSIG  equipment  managed  object  class  supports  all 
permissible  values  of  the  administrative  and  operational 
states . 

The  Createinfo  field  of  the  ObjectCreation  notification  shall 
contain  all  the  attributes  of  the  created  equipment  instance. 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  equipment  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-locationName , nmsig-contactNames , nmsig- 
equipmentPurpose , nmsig-productinfo , nmsig-vendorName , nmsig- 
userFriendlyLabel , HealthState. 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState . 


A. 4. 8.  NMSIG  IEEE  802.3 

A. 4. 8.1.  NMSIG  IEEE  802.3  Definition 


nmsig-IEEE-802.3  MANAGED  OBJECT  CLASS 
DERIVED  FROM  { top ) 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  IEEE- 802 . 3 -behaviour 
ATTRIBUTES  nmsig-IEEE-802 . 3Id  GET, 

OperationalState  GET, 
AdministrativeState  GET-REPLACE, 
nmsig-macAddress  GET-REPLACE, 
nmsig-IEEE-802. 3State  GET-REPLACE, 
nmsig-multlcastAddressList  GET-REPLACE , 
HealthState  GET 


OPERATIONS  DELETE 

ACTIONS  nmsig-executeSelfTest 

NOTIFICATIONS  ObjectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed, 
AttributeChangeUnConf irmed , 
StateChangeUnconf irmed 


REGISTERED  AS  {obj -class) 


A. 4. 8. 2.  NMSIG  IEEE  802.3  Behaviour 


iEEE-802 . 3-behaviour  BEHAVIOUR 


DEFINED  AS 
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The  managed  object  class  nmsig-IEEE-802 . 3 represents  an 
instantiation  of  an  IEEE  802.3  CSMA/CD  MAC.  It  may  contain 
either  an  nmsig-IEEE-802 . 3-XMT  managed  object,  an 
nmsig-802 . 3-RCV  managed  object,  or  both  of  these  subordinate 
objects,  as  shown  in  the  following  figure. 


NMSIG  IEEE  802.3 


+ + 

I NMSIG  IEEE  I 
I 802.3  XMT  I 
+ + 


+ + 

1 NMSIG  IEEE  I 

I 802.3  RCV  I 

+ + 


The  NMSIG  IEEE  802.3  managed  object  class  supports  only  the 
'enabled'  and  'disabled'  values  of  the  operational  state 
attribute.  The  'enabled'  value  Indicates  that  the  underlying 
IEEE  802.3  resource  is  available  for  use,  and  the  'disabled' 
value  indicates  that  the  underlying  IEEE  802.3  resource  is  not 
available  for  use. 

The  NMSIG  IEEE  802.3  managed  object  class  supports  the  DELETE 
operation;  this  operation  serves  to  reinitialize  the  CSMA/CD 
MAC. 

The  NMSIG  IEEE  802.3  managed  object  class  supports  an 
nmsig-executeSelfTest  ACTION;  this  action  causes  a self  test  to 
be  performed  on  the  referenced  managed  object  instance. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  IEEE  802.3  instance. 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  IEEE  802.3  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-macAddress , nmsig-multicastAddressList , HealthState. 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState . 


A. 4. 9.  NMSIG  IEEE  802.3  RCV 
A.4.9.1.  NMSIG  IEEE  RCV  Definition 
nmsig-IEEE-802. 3-RCV  MANAGED  OBJECT  CLASS 
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DERIVED  FROM  { top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  iEEE-802 . 3-RCV-behaviour 
ATTRIBUTES  niiisig-IEEE-802 . 3-RCVId  GET, 

OperationalState  GET, 

AdministrativeState  GET-REPLACE, 

HealthState  GET, 

nmsig-multicastRcvState  GET-REPLACE , 
PDUsReceivedCounter  GET, 
nmsig-PDUsFCSErrorCounter  GET, 
nmsig-PDUsAlignmentErrorCounter  GET , 
nmsig-PDUsInRangeLengthErrorCounter  GET , 
nmsig-PDUsOutRangeLengthErrorCounter  GET , 
nmsig-PDUsTooLongErrorCounter  GET 
OctetsReceivedCounter  GET, 
nmsig-multicastPDUsRcvCounter  GET , 
runsig-broadcastPDUsRcvCounter  GET , 
nms ig- internalMACRcvErrorCounter  GET , 

nmsig-sourceAddrLastFCSErrorPDU  GET, 
nmsig-sourceAddrLastAlignmentErrorPDU  GET , 
nmslg-sourceAddrLastlnRangeLengthErrorPDU  GET , 
nmsig-sourceAddrLastOutRangeLengthErrorPDU  GET , 
nmsig-sourceAddrLastTooLongErrorPDU  GET , 
nmsig-FCSErrorThreshold  GET-REPLACE , 
nmsig-alignmentErrorThreshold  GET-REPLACE , 
nmsig-inRangeThreshold  GET-REPLACE, 
nmsig-outRangeThreshold  GET-REPLACE , 
nmsig-frameTooLongThreshold  GET-REPLACE , 
nnisig-  internalMACRcvErrorThreshold  GET-REPLACE , 

nms ig-enablePromiscuous State  GET -REPLACE 

NOTIFICATIONS  Obj  ectCreationUnConfirmed, 

Obj  ectDeletionUnConf irmed, 

AttributeChangeUnConf irmed, 

StateChangeUnConf irmed, 

ProcessingAlarmUnConf irmed, 
nmsig-counterWrapUnConf irmed, 
CommunicationAlarmUnConf irmed 

REGISTERED  AS  {obj -class) 

A. 4. 9. 2.  NMSIG  IEEE  802.3  RCV  Behaviour 

iEEE-802 .3-RCV-behaviour  BEHJ^VIOUR 

DEFINED  AS 

The  managed  object  class  nmsig-IEEE-802 . 3-RCV  represents  an 
instantiation  of  an  IEEE  802.3  CSMA/CD  MAC  receiver.  This 
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object  may  be  contained  within  an  nmsig-IEEE-802 . 3 managed 
object. 

The  NMSIG  IEEE  802.3  RCV  managed  object  class  supports  only  the 
'enabled'  and  'disabled'  values  of  the  operational  state 
attribute.  The  'enabled'  value  indicates  that  the  underlying 
IEEE  802.3  RCV  resource  is  available  for  use,  and  the 
'disabled'  value  indicates  that  the  underlying  IEEE  802.3  RCV 
resource  is  not  available  for  use. 

The  definitive  description  of  the  counter  attributes,  their 
operation  and  precedence  is  specified  in  the  [IEEE  Doc  X]. 

The  NMSIC  IEEE  802.3  RCV  managed  object  class  supports  several 
threshold  attributes;  all  are  associated  with  the  generation  of 
a Communication  Alarm  notification. 

The  Createinfo  field  of  the  ObjectCreation  notification  shall 
contain  all  the  attributes  of  the  created  IEEE  802.3  RCV 
instance . 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  IEEE  802.3  RCV 
instance . 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-multicastRcvState , nmsig-promiscuousRcvState , nmsig- 
FCSErrorThreshold,  nmsig-alignmentErrorThreshold,  nmsig-inRan- 
geThreshold,  nmsig-outRangeThreshold,  HealthState,  nmsig- 
frameTooLongThreshold  and  nmsig-internalMACRcvErrorThreshold. 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState . 

The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 


A. 4. 10.  NMSIG  IEEE  802.3  XMT 

A. 4. 10.1.  NMSIG  IEEE  802.3  XMT  Definition 

nmsig-IEEE-802. 3-XMT  MANAGED  OBJECT  CLASS 
DERIVED  FROM  { top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  iEEE-802 . 3-XMT-behaviour 
ATTRIBUTES  nmsig-IEEE-802 . 3 -XMTId  GET, 

OperationalState  GET, 
AdministrativeState  GET-REPLACE, 
HealthState  GET, 
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nmsig-XmtState  GET-REPLACE, 

PDUsSentCounter  GET, 

nmsig-singleCollisionPDUsCounter  GET, 
nraslg-multipleCollisionPDUsCounter  GET, 
nmsig- lateCollisionsCounter  GET, 
nmsig-PDUsAbortedExcessiveCollisionsCounter  GET , 
nmsig-carrierSenseErrorsCounter  GET, 
nmsig-collisionPDUsCounter  GET, 
OctetsSentCounter  GET, 
nmsig-multicastPDUsXmtCounter  GET, 
nmsig-broadcastPDUsXmtCounter  GET, 
nmsig- PDUsLostInternalMACXmtErrorCounter  GET , 

nmsig-PDUsExcessiveDeferralCounter  GET, 
nmsig-collisionPDUsThreshold  GET-REPLACE, 
nmsig-lateCollisionsThreshold  GET-REPLACE , 
nmsig-PDUsAbortedExcessColThreshold  GET-REPLACE, 
nmsig-carrierSenseErrorsThreshold  GET-REPLACE, 
nmsig- internalMACXmtErrorThreshold  GET-REPLACE , 

nmsig- excess iveDeferralThresho Id  GET-REPLACE 

NOTIFICATIONS  Obj  ectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed, 

AttributeChangeUnConf irmed, 
CommunicationAlarmUnConf irmed, 

StateChangeUnConf irmed. 

Process ingAlarmUnConf irmed, 
runs  ig-counterWrapUnConf  irmed 
REGISTERED  AS  {obj -class} 

A. 4. 10.2.  NMSIG  IEEE  802.3  XMT  Behaviour 

iEEE-802 . 3-XMT-behaviour  BEHAVIOUR 

DEFINED  AS 

The  managed  object  class  nmsig-IEEE-802 . 3-XMT  represents  an 
instantiation  of  an  IEEE  802,3  CSMA/CD  MAC  transmitter.  This 
object  may  be  contained  within  an  nmsig-IEEE-802 . 3 managed 
obj  ect . 

The  NMSIG  IEEE  802.3  XMT  managed  object  class  supports  only  the 
'enabled'  and  'disabled'  values  of  the  operational  state 
attribute.  The  'enabled'  value  indicates  that  the  underlying 
IEEE  802.3  XMT  resource  is  available  for  use,  and  the 
'disabled'  value  indicates  that  the  underlying  IEEE  802.3  XMT 
resource  is  not  available  for  use. 

The  NMSIG  IEEE  802.3  XMT  managed  object  class  supports  both  the 
'locked'  and  'unlocked'  values  of  the  administrative  state 
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attribute.  Unlocking  the  administrative  state  serves  to  enable 
transmit  on  the  underlying  IEEE  802.3  XMT  resource. 

The  definitive  description  of  the  counter  attributes,  their 
operation  and  precedence  is  specified  in  the  [IEEE  Doc  X]. 

The  NMSIG  IEEE  802.3  XMT  managed  object  class  supports  several 
threshold  attributes;  all  are  associated  with  the  generation  of 
a CommunicatioriAlarm  notification. 

The  Createinfo  field  of  the  ObjectCreaticn  notification  shall 
contain  all  the  attributes  of  the  created  IEEE  802.3  XMT 
instance,  including  those  inherited  from  the  nmsig- equipment 
managed  object  class. 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  IEEE  802,3  XMT 
instance,  including  those  inherited  from  the  nmsig- equipment 
managed  object  class. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-collisionPDUsThreshold,  nmsig- 

lateCollisionsThreshold,  nmsig-PDUsAbortedExcessColThreshold, 
nmsig- carrierSenseErrorThreshold,  nmslg- 

internalMACXmtErrorThreshold,  nmsig-excessiveDeferralThreshold, 
Healths tate . 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState . 

The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 


A.4.11.  NMSIG  LAN  MAC  Bridge 

A. 4. 11.1.  NMSIG  LAN  MAC  Bridge  Definition 

nmsig-LAN-MAC-Bridge  MANAGED  OBJECT  CLASS 
DERIVED  FROM  { nmsig- equipment } 

CHARACACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  lAN-MAC- Bridge -behaviour 
ATTPvIBUTES  nrasig-packetLossRate  GET, 

nmsig- packetLossRateThreshold  GET-REPIACE 

NOTIFICATIONS  CommunicationAlarm 

REGISTERED  AS  {obj -class) 

A. 4. 11. 2.  NMSIG  LAN  MAC  Bridge  Behaviour 
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lAN-MAC- Bridge -behaviour  BEHAVIOUR 
DEFINED  AS 

A LAN  MAC  bridge  is  a device  which  interconnects  two  or  more 
MAC  domains.  A MAC  domain  is  an  instance  of  a MAC  algorithm 
(e.g.,  a Collision  Domain  or  a Token  Domain). 

The  L(\N  MAC  bridge  contains  two  or  more  MAC  ports  each 
associated  with  a MAC  Domain  and  operating  at  layer  two  of  the 
OSI  Model.  TTie  function  of  the  LAN  MAC  bridge  is  to  forward 
frames  from  any  one  MAC  Domain  to  one  or  more  of  the  other  MAC 
domains.  This  managed  object  class  represents  the  LAN  MAC 
bridge  device.  The  definition  of  this  managed  object  class  is 
based  upon  the  IEEE  802.1  D specification. 

The  NMSIG  LAN  MAC  bridge  managed  object  class  supports  only  the 
'enabled'  and  'disabled'  values  of  the  operational  state 
attribute.  The  'enabled'  value  indicates  that  the  underlying 
LAN  MAC  bridge  resource  is  available  for  use,  and  the 
'disabled'  value  indicates  that  the  underlying  LAN  MAC  bridge 
resource  is  not  available  for  use. 

The  Createinfo  field  of  the  ObjectCreation  notification  shall 
contain  all  the  attributes  of  the  created  LAN  MAC  Bridge 
instance . 

The  Deletelnfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  IAN  MAC  Bridge 
instance . 

i\ttributes,  additioal  to  those  that  have  been  inherited  from 
Equipment,  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-packetLossRateThreshold. 


A. 4, 12.  NMSIG  MAC  Port 

A. 4. 12.1,  mSIG  MAC  Port  Definition 

runs ig-MAC- Port  M/d^AGED  OBJECT  CLASS 

DERIVED  FROM  { top ) 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  mAC- Port -behaviour 
ATTRIBUTES  nmsig-MAC-PortId  GET, 

nmsig-MAC-PortInNonUCastPktsCounter  GET, 
nmsig-MAC-PortOutNonUCastPktsCounter  GET, 
nmsig-MAC-PortInUCastPktsCounter  GET, 
nmsig-MAC-PortOutUCastPktsCounter  GET, 
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nmsig-MAC-PortOutDelayDiscPktsCounter  GET , 
nmsig-MAC-PortOutQLen  GET, 
nmsig-MAC-PortlnOctetRate  GET, 
nmsig-MAC-PortInOctetRateThreshold  GET-REPLACE , 
AdministrativeState  GET-REPLACE, 

OperationalState  GET, 

Healths tate  GET, 

ninsig-broadcastForwardingState  GET-REPLACE, 
nmsig-mult leas tForwardingS tate  GET-REPLACE 

NOTIFICATIONS  Obj ectCreationUnConf irmed, 

Obj  ec tDe letionUnConf irmed , 

AttributeChangeUnConf irmed , 

StateChangeUnConf irmed, 
nms ig- counterWrapUnConf irmed , 

Communi c a t i onA 1 armUnC onf i rme d 

REGISTERED  AS  {obj -class) 

A, 4 . 12 . 2 . NMSIG  MAC  Port  Behaviour 

mAC- Port -behaviour  BEHAVIOUR 

DEFINED  AS 

This  managed  object  class  represents  a MAC  Port.  A MAC  Port  is 
contained  in  a LAN  MAC  Bridge.  It  provides  the  physical 
connection  to  a MAC  Domain. 

The  NMSIG  MAC  Port  managed  object  class  supports  only  the 
'enabled'  and  'disabled'  values  of  the  operational  state 
attribute.  The  'enabled'  value  indicates  that  the  underlying 
MAC  Port  resource  is  available  for  use,  and  the  'disabled' 
value  indicates  that  the  underlying  MAC  port  resource  is  not 
available  for  use. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  MAC  Port  instance. 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  MAC  Port  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  HealthState,  nmsig-MAC-PortlnOctetsRateThreshold,  nmsig- 

broadcastForwardingState  and  nmsig-multicastForwardingState . 

Attributes  that  are  subject  to  the  StateChange  notification 
are:  AdministrativeState  and  OperationalState. 
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The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 


A. 4. 13.  NMSIG  Network 

A. 4. 13.1.  NMSIG  Network  Definition 

nmsig-network  MANAGED  OBJECT  CLASS 

DERIVED  FROM  { top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  network -behaviour 
ATTRIBUTES  nmsig-networkid  GET, 

nmsig-networkPurpose  GET, 
nmsig-userFriendlyLabel  GET-REPLACE 

NOTIFICATIONS  ObjectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed, 

At tributeChangeUnConf irmed 

REGISTERED  AS  {obj -class} 

A. 4. 13.2.  NMSIG  Network  Behaviour 

network-behaviour  BEHAVIOUR 

DEFINED  AS 

The  NMSIG  Network  managed  object  class  represents  a collection 
of  connecting  and  interconnected  resources  (logical  and 
physical)  capable  of  exchanging  information.  A network  may  be 
contained  in  another  network,  thereby  creating  a 
superior/subordinate  relationship . 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  network  instnace. 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  network  instance. 

Attributes  that  are  subject  to  the  AttributeChange  notification 
are:  nmsig-networkPurpose , nmsig-userFriendlyLabel 


A. 4. 14.  NMSIG  Processing  Entity 

A. 4. 14,1.  NMSIG  Processing  Entity  Definition 

nmsig-processingEntity  MANAGED  OBJECT  CLASS 
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DERIVED  FROM  { runs ig- equipment ) 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  processingEntity-behaviour 
ATTRIBUTES  nmsig-cPU-Type  GET, 

nmsig-memorySize  GET, 
runsig-oslnfo  GET, 
nmsig-entityUpTime  GET 

OPERATIONS  DELETE 

NOTIFICATIONS  ProcessingAlarmUnConf irmed 

REGISTERED  AS  {obj -class) 

A. 4. 14.2.  NMSIG  Processing  Entity  Behaviour 
processingEntity-behaviour  BEHAVIOUR 
DEFINED  AS 

The  NMSIG  processing  entity  managed  object  class  represents  the 
physical  portion  of  the  computer  system  that  performs  the 
processing  function.  A processing  entity  may  be  composed  of 
such  components  as  arithmetic  logic  units  (ALUs)  registers  for 
processing  memory,  limited  storage  often  in  the  form  of  Random 
Access  Memory  (RAM) , and  various  other  types  of  memory  used  in 
the  processing  function.  It  does  not  include  components  such 
as  disk  drives,  data  bases,  etc. 

Some  processing  entities  may  have  input/output  channels, 
particularly  when  hardware  is  shared  between  elements  of  the 
processing  entity.  In  other  cases,  the  input/output  may  be 
viewed  as  components  of  a superior  object,  e.g,  a computer 
system,  or  even  shared  among  several  computer  systems. 

The  NMSIG  processing  entity  managed  object  class  supports  all 
the  values  of  the  administrative  state.  It  supports  only  the 
enabled  and  disabled  values  of  the  operational  state.  An 
instance  of  the  NMSIG  Processing  Entity  managed  object  class 
must  be  created  before  any  of  its  subordinates  are  created. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  processing  entity 
instance . 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  processing  entity 
instance . 
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Attributes,  additional  to  those  inherited  from  Equipment,  that 
are  subject  to  the  AttributeChange  notification  are:  nmsig- 
cPU-Type,  nmsig-memorySize , nmsig-osinfo 

A. 4. 15.  MMSIG  Root 

A. 4. 15.1.  NMSIG  Root  Definition 

nmsig-root  MANAGED  OBJECT  CLASS 

DERIVED  FROM  top 
CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  root -behaviour 
REGISTERED  AS  {obj -class) 

A. 4. 15.2.  NMSIG  Root  Behaviour 
root-behaviour  BEHAVIOUR 
DEFINED  AS 

This  managed  object  class  is  used  to  represent  the  most 
superior  object  instance  in  the  containment  tree.  The  purpose 
of  this  managed  object  class  is  to  serve  as  the  common  point 
from  which  all  instances  of  managed  object  classes  are  named. 

A single  instance  of  this  managed  object  class  is  always 
present  in  every  system,  with  a distinguished  name  that  is  a 
null  sequence  (i.e.  a SEQUENCE  OF  with  a length  of  zero). 


A. 4. 16.  NMSIG  Transport  Connection 

A. 4. 16.1.  NMSIG  Transport  Connection  Definition 


nmsig- transportConnection  MANAGED  OBJECT  CLASS 

DERIVED  FROM  { top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  transportConnection-behaviour 
ATTRIBUTES  nmsig- transportConnectionId  GET, 

nmsig- localTransportConnectionEndpoint  GET , 
nrasig-remoteTransportConnectionEndpoint  GET , 
nmsig- transportConnec tionRef erence  GET , 
nmsig- localNetworkAddress  GET, 
nmsig-remoteNetworkaddress  GET, 
nmsig- inactivityTimeout  GET, 
nmsig-maxPDuSize  GET, 

PDUsSentCounter  GET, 
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PDUsReceivedCounter  GET, 
OctetsSentCounter  GET, 
OctetsReceivedCounter  GET, 
Peer  GET 


OPERATIONS 


DELETE  deletes  contained  objects 


NOTIFICATIONS 


ObjectCreationUnConf irmed, 

Obj  ectDeletionUnConf irmed. 

Re lationshipChangeUnConf irmed , 
nmsig-counterWrapUnConf irmed 


PACKAGE 


runs  ig-transportConnectionRe  transmission 
PRESENT  IF  transport  protocol  supports  retransmission 


REGISTERED  AS  {obj -class) 

A. 4. 16. 2.  NMSIG  Transport  Connection  Behaviour 
transportConnect ion-behaviour  BEHAVIOUR 
DEFINED  AS 

The  managed  object  class  nmsig- transportConnection  represents 
an  active  transport  connection  (e.g.,  an  OSI  transport 
connection  or  a TCP  connection) . A transport  connection  is 
established  and  used  by  two  peer  connection  oriented  transport 
protocol  layer  entities  for  the  purpose  of  transferring  data. 

A connection  oriented  transport  protocol  layer  entity  may 
support  multiple  transport  connections. 


This  managed  object  class  represents  a "generic"  view  of  a 
transport  connection.  It  does  not  concern  itself  with  the 
details  of  specific  transport  protocols  like  ISO  TP  or  TCP. 
Transport  connections  that  are  tied  to  a specific  protocol  can 
be  defined  as  its  subclasses;  in  fact  their  definitions  are 
being  progressed  within  various  standards'  bodies.  The  purpose 
of  defining  this  managed  object  class,  however,  is  to  provide  a 
common  base  that  will  facilitate  the  high  level  management  of 
similar  but  slightly  differing  resources. 

The  expected  real  effect  of  the  DELETE  operation  when  applied 
to  an  instance  of  the  NMSIG  transport  connection  managed  object 
class  is  that  the  underlying  transport  connection  resource  is 
aborted. 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
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contain  all  the  attributes  of  the  created  transport  connection 
instance . 

The  Deleteinfo  field  of  the  ObjectDeletion  notification  shall 
contain  all  the  attributes  of  the  created  transport  connection 
instance.  In  addition  it  shall  also  contain  a 'cause' 
parameter  defined  as  follows: 

cause  : :=  SEQUENCE  { 

INTEGER  ( unknown  ( 0 ) , 
user  (1) , 
provider  (2)), 

INTEGER  (unknown  (0) , 
local  (1) , 
remote  (2) ) , 

INTEGER  (unknown  (0) , 

excessiveldle  (1), 
excessiveRtx  (2)) 

) 

The  counterWrap  notification  is  emitted  when  any  of  the  counter 
attributes  wrap. 

The  RelationshipChange  notification  is  emitted  whenever  the 
peer  attribute  changes  in  value. 


A.4.16.3.  NMSIG  Transport  Connection  Retransmission  Package 

nmsig- transportConnectionRetransmission  CONDITIONAL  PACKAGE 

BEHAVIOUR  DEFINITIONS  transportConnectionRetransmission- 

behavlour 

ATTRIBUTES  nmsig-maxRetransmissions  GET, 

nmsig-retransmissionTimerInitialValue  GET , 
PDUsRetransmittedErrorCounter  GET , 
PDUsRetransraittedRate  GET, 

PDUsRetransmittedRateThreshold  GET-REPLACE , 
nmsig-octetsRetransmitted  GET 

NOTIFICATIONS  AttributeChange 

CommunicationAlarmUnConf irmed 

REGISTERED  AS  (package) 

transportConnectionRe transmission-behaviour  BEHAVIOUR 
DEFINED  AS 

This  package  reflects  the  retransmitting  capability  of  the 
underlying  transport  protocol  resource. 
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Attributes  that  are  subject  to  the  AttributeChange  notification 
are : PDUsRetransmittedilateThreshold. 


A. 4. 17.  NMSIG  Transport  Coimection  Profile 

A. 4. 17.1.  NMSIG  Transport  Coimection  Profile  Definition 

nmsig- transportConnectionProf ile  MANAGED  OBJECT  CLASS 

DERIVED  FROM  { top } 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  trasnportConnectionProf ile-behaviour 
ATTRIBUTES  nmsig- transportConnectionProf ileld  GET, 

nmsig-  inacti.vityTimeout  GET -REPLACE , 
nmsig-maxTPDuSize  GET-REPLACE 

OPERATIONS  CREATE, 

DELETE 

NOTIFICATIONS  Obj ectCreation 
Obj  ectDeletion 
AttributeChange 

REGISTERED  AS  {obj -class} 

A. 4. 17. 2.  NMSIG  Transport  Connection  Profile  Behaviour 
transportConnectionProf ile-behaviour  BEHAVIOUR 
DEFINED  AS 

This  managed  object  class  represents  the  collection  of 
characteristic  attributes  which  supply  default  and  initially 
advertised  attribute  vaJ.ues  to  be  used  by  instances  of  the 
NMSIG  Transport  Connection  managed  object  class  when  they  are 
created.  There  can  be  onl3r  one  instance  of  the  NMSIG  Transport 
Connection  Profile  managed  object  class  for  each  instance  of 
the  NMSIG  CO  Transport  Protocol  Layer  Entity  managed  object 
class . 

The  Createinfo  field  of  the  Obj ectCreation  notification  shall 
contain  all  the  attributes  of  the  created  transport  connection 
profile  instance. 

The  Deleteinfo  field  of  the  Obj ectDeletion  notification  shall 
contain  all  the  attributes  of  the  deleted  transport  connection 
profile  Instance. 

Attributes  that  are  .subject  to  the  AttributeChange  notification 
are:  nmsig- inactivityTimeout , nmsig-maxTPDuSize . 
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A. 4. 18.  MMSIG  Transport  Connection  Retransmission  Profile 

A. 4. 18.1.  NMSIG  Transport  Connection  Retransmission  Profile 

Definition 

nnisig- transportConnectiohRetransmissionProfile  MANAGED  OBJECT  CLASS 

DERIVED  FROM  nmsig- transportConnectionProf ile 

CHARACTERIZED  BY 

BEHAVIOUR  DEFINITIONS  transportConnectionProf ile -behaviour 
attributes  nmsig-maxRe transmissions  GET-REPLACE, 

nmsig- re transmissionTimerInitialValue  GET-REPLACE 

REGISTERED  AS  {obj -class} 

A. 4. 18. 2.  NMSIG  Transport  Connection  Retransmission  Profile 
Behaviour 

transportConnectionRetransmissionProf ile -behaviour  BEHAVIOUR 
DEFINED  AS 

This  managed  object  class  represents  the  collection  of 
characteristic  attributes  which  supply  default  and  initially 
advertised  attribute  values  to  be  used  by  instances  of  the 
NMSIG  Transport  Connection  managed  object  class  that  support 
retransmission,  when  they  are  created.  There  can  be  only  one 
instance  of  the  NMSIG  Transport  Connection  Retransmission 
Profile  managed  object  class  for  each  instance  of  the  NMSIG  CO 
Transport  Protocol  Layer  Entity  managed  object  class. 

Attributes,  additional  to  those  inherited  from  the  transport 
connection  profile  managed  object  class,  that  are  subject  to 
the  AttributeChange  notification  are  : nmsig- 
maxRetransmissions , nmsig-retransmissionTimerInitialValue 


A. 4. 19.  Top 

This  managed  object  class  represents  the  root  of  the  inheritance  tree. 
Refer  to  [ISO  Doc  x]  for  the  definition  of  this  managed  object  class. 
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A. 5.  NAME  BINDINGS 

This  section  provides  definitions  of  NAME  BINDINGS  for  the  managed 
object  classes  defined  by  the  OSI  MIB  Working  Group.  NAME  BINDINGS 
for  managed  object  classes  defined  by  other  groups  can  be  found  in  the 
document  referenced  under  the  managed  object  class  definition  in 
section  3. 

A. 5.1.  Event  Forwarding  Discriminator  Name  Bindings 

EventForwardingDiscriminator-nb-1  NAME  BINDING 

EventForwardingDiscriminator  IS  NAMED  BY  nmsig-agent 
WITH  ATTRIBUTE  Discriminatorld 

REGISTERED  AS  (nmsig-nb) 

A. 5. 2.  NMSIG  Agent  Name  Bindings 

nms ig- agent -nb - 1 NAME  BINDING 

nmsig-agent  IS  NAMED  BY  nmsig-root 

WITH  ATTRIBUTE  nmsig-agentid 

REGISTERED  AS  {nmsig-nb) 

A. 5. 3.  NMSIG  Computer  System  Name  Bindings 

nmsig-computerSystem-nb-1  NAME  BINDING 

nmsig-computerSystem  IS  NAMED  BY  nmsig-network 
WITH  ATTRIBUTE  nmsig-systemid 

REGISTERED  AS  (nmsig-nb) 

nmsig-computerSystem-nb-2  NAME  BINDING 

nmsig-computerSystem  IS  NAMED  BY  nms ig-computerSys tern 
WITH  ATTRIBUTE  nmsig-systemid 

REGISTERED  AS  (nmsig-nb) 

nmsig-computerSystem-nb-3  NAME  BINDING 
nrasig-computerSystem  IS  NAMED  BY  nmsig-root 
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WITH  ATTRIBUTE  nmsig-systemid 
REGISTERED  AS  (runsig-nb) 

A. 5. 4.  NMSIG  CO  Transport  Protocol  Layer  Entity  Name  Bindings 

nmsig-coTransportProtocolLayerEntity-nb-1  NAME  BINDING 

nmsig-coTransportProtocolLayerEntity  IS  NAMED  BY  nmsig- 
computerSystem 

WITH  ATTRIBUTE  nmsig-coTransportEntityld 
REGISTERED  AS  (nmsig-nb) 

nmsig-coTransportProtocolLayerEntity-nb-2  NAME  BINDING 

nmsig-coTransportProtocolLayerEntity  IS  NAMED  BY  nmsig- equipment 
WITH  ATTRIBUTE  nmsig-coTransportEntityld 

REGISTERED  AS  (nmsig-nb) 

A. 5. 5.  NMSIG  CL  Network  Protocol  Layer  Entity  Name  Bindings 

nmsig-clNetworkProtocoLLayerEntity-nb- 1 NAME  BINDING 

nmsig-clNetworkProtocolLayerEntity  IS  NAMED  BY  nmsig-computerSystem 
WITH  ATTRIBUTE  nmsig-clNetworkProtocolEntityld 

REGISTERED  AS  {nmsig-nb} 

nmsig-clNetworkProtocolLayerEntity-nb-2  NAME  BINDING 

nmsig-clNetworkProtocolLayerEntity  IS  NAMED  BY  nmsig- equipment 
WITH  ATTRIBUTE  nmsig-clNetworkProtocolEntityld 

REGISTERED  AS  {nmsig-nb} 

A. 5. 6.  NMSIG  Equipment  Name  Bindings 

nms ig- equipment - nb - 1 NAME  BINDING 

nmsig- equipment  IS  NAMED  BY  nmsig- equipment 
WITH  ATTRIBUTE  nmsig-equipmentid 

REGISTERED  AS  {nmsig-nb} 
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nmsig-equipment-nb-2  NAME  BINDING 

runs ig- equipment  IS  NAMED  BY  nmsig-network 
WITH  ATTRIBUTE  nmsig-equipmentid 
REGISTERED  AS  {nmsig-nb} 


nmsig-equipment-nb- 3 NAME  BINDING 

nmsig- equipment  IS  NAMED  BY  nmsig-root 
WITH  ATTRIBUTE  nmsig-equipmentid 

REGISTERED  AS  {nmsig-nb) 

A.  5. 7.  NMSIG  IEEE  802.3  Name  Bindings 

nmsig-IEEE-802. 3-nb-l  NAME  BINDING 

nmsig-IEEE-802 . 3 IS  NAMED  BY  nmsig-network 
WITH  ATTRIBUTE  nmsig-IEEE-802 . 3Id 

REGISTERED  AS  {nmsig-nb} 

nmsig-IEEE-802. 3-nb-2  NAME  BINDING 

nmsig-IEEE-802 . 3 IS  NAMED  BY  nmsig-computerSystem 
WITH  ATTRIBUTE  nmsig- IEEE-802 . 3Id 

REGISTERED  AS  {nmsig-nb} 

A. 5. 8.  NMSIG  IEEE  802.3  RCV  Name  Bindings 

nmsig-IEEE-802. 3-RCV-nb-l  NAME  BINDING 

nmsig-IEEE-802 . 3-RCV  IS  NAMED  BY  nmsig-IEEE-802 . 3 
WITH  ATTRIBUTE  nmsig-IEEE-802 . 3-RCVId 

REGISTERED  AS  {nmsig-nb} 

A. 5. 9.  NMSIG  IEEE  802.3  XMT  Name  Bindings 

nmsig-IEEE-802. 3-XMT-nb-l  NAME  BINDING 

nmsig-IEEE-802. 3-XMT  IS  NAMED  BY  nmsig-IEEE-802 . 3 
WITH  ATTRIBUTE  nmsig-IEEE-802 . 3-XMTId 
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REGISTERED  AS  {nmsig-nb} 

A. 5. 10.  KMSIG  LAN  MAC  Bridge  Name  Bindings 

nmsig-LAN-MAC-Bridge-nb-1  NAME  BINDING 
nmsig-LAN-MAC-Bridge  IS  NAMED  BY  runs ig- network 
WITH  ATTRIBUTE  runs  ig- equipment  Id 

REGISTERED  AS  {nmsig-nb} 

A.  5. 11.  NMSIG  MAC  Port  Name  Bindings 

nmsig-MAC-Port-nb-1  NAME  BINDING 

nmsig-MAC-Port  IS  NAMED  BY  nmsig-LAN-MAC-Bridge 
WITH  ATTRIBUTE  nmsig-MAC-PortId 

REGISTERED  AS  (nmsig-nb) 

A. 5. 12.  NMSIG  Network  Name  Bindings 

nmsig-network-nb- 1 NAME  BINDING 

nmsig-network  IS  NAMED  BY  nmsig-network 
WITH  ATTRIBUTE  nmsig-networkid 

REGISTERED  AS  (nmsig-nb) 


nmsig-network-nb-2  NAME  BINDING 

nmsig-network  IS  NAMED  BY  nmsig-root 
WITH  ATTRIBUTE  nmsig-networkid 

REGISTERED  AS  (nmsig-nb) 

A. 5. 13.  NMSIG  Processing  Entity  Name  Bindings 

nmsig-processingEntity-nb-1  NAME  BINDING 

runsig-processingEntity  IS  NAMED  BY  nmsig-computerSystem 
WITH  ATTRIBUTE  runs  ig- equipment  Id 

REGISTERED  AS  (nmsig-nb) 

A. 5. 14.  NMSIG  Transport  Corusection  Name  Bindings 
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nmsig- transportConnection-nb- 1 NAME  BINDING 

nmsig- transportConnection 

IS  NAMED  BY  nmsig- coTransportProtocolLayerEntlty 
WITH  ATTRIBUTE  nmsig- transportConnectionld 

REGISTERED  AS  (nmsig-nb) 

A. 5. 15.  NMSIG  Transport  Connection  Profile  Name  Bindings 

nmsig- transportConnectionProfile-nb-1  NAME  BINDING 

nmsig- transportConnectionProfile 

IS  NAMED  BY  nmsig-coTransportProtocolLayerEntity 
WITH  ATTRIBUTE  nmsig- transportConnectionProfileld 

REGISTERED  AS  {nmsig-nb} 

A. 5. 16.  NMSIG  Transport  Connection  Retransmission  Profile  Name 

Bindings 

nmsig-transportConnectionRetransmissionProf ile-nb-1  NAME  BINDING 

nmsig- transportConnectionRetransmissionProfile 

IS  NAMED  BY  nmsig-coTransportProtocolLayerEntity 
WITH  ATTRIBUTE  nmsig- transportConnectionProfileld 

REGISTERED  AS  {nmsig-nb} 
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A. 6.  ATTRIBUTES 

This  section  provides  definitions  of  attributes  contained  in  the 
managed  object  classes  defined  by  the  OSI  MIB  Working  Group. 
Attribute  definitions  for  managed  object  classes  defined  by  other 
groups  can  be  found  in  the  document  referenced  under  the  managed 
object  class  definition  in  section  3. 

A. 6.1.  Administrative  State 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A. 6. 2.  Begin  Time 

Refer  to  [ISO  Doc  x]  for  the  'iefinition  of  this  attribute. 

A. 6. 3.  Destination  Address 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A. 6. 4.  Discriminator  Construct 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A . 6 . 5 . Discriminator  Id 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A.  6. 6.  End  Time 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A. 6. 7.  Health  State 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 

A. 6. 8.  Incoming  Connection  Reject  Error  Counter 

Refer  to  [ISO  Doc  X]  for  the  definition  of  this  attribute. 

A. 6. 9.  Incoming  Connection  Requests  Counter 
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Refer  to  [ISO  Doc  X]  for  the  definition  of  this  attribute. 

A. 6. 10.  Incoming  Disconnect  Error  Counter 

Refer  to  [ISO  Doc  X]  for  the  definition  of  this  attribute. 


A. 6. 11.  Incoming  Temporal  Error  Counter 

Refer  to  [ISO  Doc  X]  for  the  definition  of  this  attribute. 


A. 6. 12.  NMSIG  Alignment  Error  Threshold 

nmsig-alignmentErrorThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  alignmentErrorThreshold-behaviour 
REGISTERED  AS  [ninsig-attr ) 

GaugeThreshold  ; :=  {as  defined  in  ISO  Doc  X) 
alignmentErrorThresho Id- behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  alignment  error  rate.  The  alignment  error  rate  is  defined 
as  the  number  of  PDUs  received  with  alignment  errors  divided  by 
the  total  number  of  PDUs  received.  A communication  alarm 
notification  is  emitted  when  the  alignment  error  rate  exceeds 
the  threshold  value. 

A. 6. 13.  NMSIG  Agent  Id 

nmsig-agentid  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
BEHAVIOUR  agentid-behaviour 
REGISTERED  AS  {nmsig-attr} 

agentid-behaviour  BEHAVIOUR 

DEFINED  AS 

This  is  the  distinguishing  attribute  for  the  managed  object 
class  NMSIG  Agent. 


A. 6. 14.  NMSIG  Broadcast  Fcrwarding  State 
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nrasig-broadcastForwardingState  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  State 
MATCHES  FOR  Equality 

BEliAVIOUR  broadcastForwardingState  "behaviour 

REGISTERED  AS  (nmsig-attr } 

State  ::=  ENUMERATED  {off  (0). 

on  (1)} 


broadcastForwardingState -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  whether  broadcast  PDUs  are  being 
forwarded. 


A. 6. 15.  NMSIG  Broadcast  PDUs  Rev  Counter 

nmsig-broadcastPDUsRcvCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  broadcastPDUsRcvCounter-behaviour 

REGISTERED  AS  {nirsig-attr} 

Count  : (as  defined  in  ISO  Doc  X) 

broadcastPDUsRcvCounter-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  broadcast  PDUs  received 
ok  by  the  underlying  NMSIG  IEEE  802.3  RCV  resource. 

A. 6. 16.  NMSIG  Broadcast  PDUs  Xmt  Counter 

nmsig-broadcastPDUsXmtOkCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  broadcastPDUsXmtOkCounter-behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : {as  defined  in  ISO  Doc  X) 

broadcastPDUsXifitOkCounter -behaviour  BEHAVIOUR 
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DEFINED  AS 

This  attribute  specifies  the  number  of  broadcast  PDUs  which 
were  transmitted  ok  by  the  underlying  NMSIG  IEEE  802.3  XMT 
resource . 

A. 6. 17.  NMSIG  Carrier  Sense  Errors  Counter 

nmsig-carrierSenseErrorsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  carrierSenseErrorsCounter-behaviour 

REGISTERED  AS  {nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X} 

carrierSenseErrorsCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  carrier  sense  Errors 
which  were  detected  by  the  underlying  NMSIG  IEEE  802.3  XMT 
resource . 


A. 6. 18.  NMSIG  Carrier  Sense  Errors  Threshold 

nmsig-carrierSenseErrorsThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  carrierSenseErrorsThreshold-behaviour 
REGISTERED  AS  {nmsig-attr) 

GaugeThreshold  : :=  {as  defined  in  ISO  Doc  X) 
carrierSenseErrorsThreshold-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  carrier  sense  error  rate.  The  carrier  sense  error  rate  is 
defined  as  the  carrier  sense  errors  detected  per  second.  A 
communication  alarm  notification  is  emitted  v/hen  the  carrier 
sense  error  rate  exceeds  the  threshold  valiae. 


A. 6. 19.  NMSIG  Checksum  TPDUs  Discarded  Counter 
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nmsig-checks'omTPDUsDiscardedCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 

BEHAVIOUR  checksumTPDUsDiscardedCounter-behaviour 

REGISTERED  AS  {nmsig-attr ) 

Count  : :=  {as  defined  in  ISO  Doc  X) 
checksumTPDUsDiscardedCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  niimber  of  TPDUs  discarded  due  to  a 
bad  checksum. 


A.  6. 20.  NMSIG  Collision  PDUs  Counter 

nmsig-collisionPDUsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  col 1 is ionPDUsCounter -behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  (as  defined  in  ISO  Doc  X) 

CO  11  is  ionPDUsCounter -behaviour  BEH/AVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  collision  PDUs  which 
were  detected  by  the  underlying  NMSIG  IEEE  802.3  XMT  resource. 


A. 6. 21.  NMSIG  Collision  PDUs  Threshold 

nmsig-collisionPDUsThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  CO 1 1 i s ionPDUsThre  sho Id-behavi our 
REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  : :=  (as  defined  in  ISO  Doc  X) 
collisionPDUsThreshold-behaviour  BEHAVIOUR 
DEFINED  AS 
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This  attribute  specifies  a threshold  which  is  applied  against 
the  collision  PDU  rate.  The  collision  PDU  rate  is  defined  as 
the  collision  PDUs  detected  per  second.  A communication  alarm 
notification  is  emitted  when  the  collision  PDU  rate  exceeds  the 
threshold  value. 


A. 6. 22.  NMSIG  CO  Transport  Protocol  Layer  Entity  Id 

nmsig-coTransportEntityld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 

BEHAVIOUR  coTransportEntity Id-behaviour 
REGISTERED  AS  {nmsig-attr} 

coTransportEntityID-behaviour  BEHAVIOUR 
DEFINED  AS 

This  is  the  distinguishing  attribute  for  the  managed  object 
class  connection  oriented  transport  protocol  layer  entity. 


A.  6. 23.  NMSIG  Connectionless  Network  Protocol  Layer  Entity  Id 

runs  ig- c INe  two  rkPro  toco  ILayerEntity  Id  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 

BEHAVIOUR  c iNe two rkPro toco ILayerEntity Id-behaviour 
REGISTERED  AS  (nmsig-attr) 

c INe two rkPro toco ILayerEntity Id-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  for  the  managed 
object  class  clNetworkProtocolLayerEntity . 


A. 6. 24.  NMSIG  Contact  Names 

nmsig-contactNames  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  AnyNarae 

MATCHES  FOR  Set  Comparison,  Set  Intersection 

BEHAVIOUR  contactNaraes -behaviour 

REGISTERED  AS  {nmsig-attr} 
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AnyName  : :=  SET  OF  (CHOICE  {dn  DistinguishedName , 

ps  PrintableString) ) 

contactNames -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  name(s)  of  one  or  more  contacts. 


A. 6. 25.  NMSIG  CPU  Type 

runsig-cPU-Type  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  cPU-Type -behaviour 

REGISTERED  AS  {nmsig-attr} 

cPU-Type -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  type  of  the  Central  Processor  Unit 
in  a processing  entity. 

A. 6. 26.  NMSIG  Enable  Promiscuous  State 

nmsig-enablePromiscuous State  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  State 
MATCHES  FOR  Equality 

BEHAVIOUR  enablePromiscuous State -behaviour 

REGISTERED  AS  {nmsig-attr) 

State  ENUMERATED  (off  (0), 

on  ( 1 ) ) 

enablePromiscuousState -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  whether  the  IEEE  802.3  RCV  is 
operating  in  promiscuous  mode. 

A. 6. 27.  NMSIG  Entity  Up  Time 

nmslg-entityUpTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
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MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  entityUpTime-behaviour 

REGISTERED  AS  (nrasig-attr) 

entityUpTime-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  time  interval  (in  seconds)  that 
has  elapsed  since  the  time  that  the  value  of  the  entity's 
operational  state  changed  from  'disabled'  to  some  other  value, 
or  since  the  time  that  the  entity  was  created  into  a non 
disabled  state. 

A. 6. 28.  NMSIG  Equipment  Id 

nmsig-equipmentid  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  equipmentid-behaviour 

REGISTERED  AS  {nmsig-attr } 

equipmentid-behaviour  BEHAVIOUR 

DEFINED  AS 

This  is  the  distinguishing  attribute  of  the  NMSIG  equipment 
managed  object  class. 


A.  6. 29.  NMSIG  Equipment  Purpose 

nmsig-equipmentPurpose  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  equipmentPurpose -behaviour 

REGISTERED  AS  {nmsig-attr} 

equipmentPurpose -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  what  the  equipment  is  used  for  (e.g., 
switching,  processing,  etc.). 


A. 6. 30.  NMSIG  Excessive  Deferral  Threshold 
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nmsig- excess iveDeferralThresho Id  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  excess iveDeferralThresho Id-behaviour 
REGISTERED  AS  {nmsig-attr} 

GaugeThreshold  : {as  defined  in  ISO  Doc  X} 
excess iveDeferralThreshold-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  excessive  deferral  rate.  The  excessive  deferral  rate  is 
defined  as  the  number  of  excessive  deferral  PDUs  transmitted 
per  second.  A communication  alarm  notification  is  emitted  when 
the  excessive  deferral  rate  exceeds  the  threshold  value. 


A.  6. 31.  NMSIG  FCS  Error  Threshold 

nmsig-FCSErrorThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  fCSErrorThresho Id-behaviour 

REGISTERED  AS  {nmsig-attr) 

GaugeThreshold  : {as  defined  by  ISO  Doc  X} 

fCSErrorThresho Id-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  FCS  error  rate.  The  FCS  error  rate  is  defined  as  the 
number  of  PDUs  received  which  had  FCS  errors  divided  by  the 
total  number  of  PDUs  received.  A communication  alarm 
notification  is  emitted  when  the  FCS  error  rate  exceeds  the 
threshold  value. 


A. 6. 32.  NMSIG  IEEE  802.3  Id 

nmsig-IEEE-802.3Id  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  IEEE- 802 . 3Id-behaviour 
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REGISTERED  AS  {nnisig-attr ) 

iEEE-802.3ld-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  of  the  NMSIG 
IEEE  802.3  managed  object  class. 


A. 6. 33.  NMSIG  IEEE  802.3  RCV  Id 

ninsig-IEEE-802.3-RCVId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  iEEE-802 . 3-RCVId-behaviour 

REGISTERED  AS  {nmsig-attr } 
iEEE-802 . 3-RCVId-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  of  the  NMSIG 
IEEE  802.3  RCV  managed  object  class. 


A. 6. 34.  NMSIG  IEEE  802.3  State 

nmsig- IEEE- 802 . 3 State  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  EnabieState 
MATCHES  FOR  Equality 
BEHAVIOUR  iEEE-802 . 3State-behaviour 

REGISTERED  AS  {ninsig-attr } 

EnabieState  : :=  ENUMERATED  {disable  (0), 

enable  (1)) 

iEEE-802 . 3State-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  whether  the  IEEE  802.3  object  is 
enabled  or  not.  The  'enabled'  and  'disabled'  values  of  this 
attribute  correspond  to  the  'enabled'  and  'disabled'  values  of 
the  OperationalState  attribute.  (This  attribute  was  introduced 
as  a GET-REPLACE  attribute  which  can  be  used  by  management  to 
enable  or  disable  the  underlj'^ing  IEEE  802.3  resource.) 
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A. 6. 35.  NMSIG  IEEE  802.3  XMT  Id 

niiisig-IEEE-802.3-XMTId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  iEEE-802 . 3-XMTId-behaviour 

REGISTER.ED  AS  {nriisig-attr ) 

iEEE-802 . 3-XMTId-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  of  the  NMSIG 
IEEE  802.3  XMT  managed  object  class. 


A. 6. 36.  NMSIG  In-Range  Threshold 

ninsig-inRangeThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  inRangeThesho Id-behaviour 

REGISTERED  AS  {nmsig-attr} 

GaugeThreshold  : :=  {as  defined  by  ISO  Doc  X) 

inRangeTheshold-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  in- range  length  error  rate.  The  in- range  length  error  rate 
is  defined  as  the  number  of  PDUs  received  that  had  in-range 
length  errors  divided  by  the  total  number  of  PDUs  received.  A 
conimunication  alarm  notification  with  the  specified  severity  is 
emitted  when  the  in-range  length  error  rate  exceeds  the 
threshold  value. 


A. 6. 37.  NMSIG  Inactivity  Timeout 

nmsig-inactivityTimeout  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  inactivityTimeout-behaviour 

REGISTERED  AS  (nmsig-attr) 
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inactivityTimeout -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  maximum  amount  of  time  (in 
1/lOOths  of  a second)  that  the  transport  connection  can  remain 
up  when  there  is  no  activity  ( i.e.  data  flow  ) on  it.  A value 
of  0 for  this  attribute  indicates  that  an  inactivity  timeout  is 
not  supported  on  the  transport  connection. 


A. 6. 38.  NMSIG  Incoming  Normal  Disconnect  Cotinter 

nmsig-incomlngNormalDisconnectCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  incomingNormalDisconnectCounter -behaviour 

REGISTERED  AS  {nrasig-attr ) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

incomingNormalDisconnectCounter -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  incoming  transport 
connections  that  were  disconnected  due  to  normal  reasons. 


A. 6. 39,  NMSIG  Internal  MAC  Rev  Error  Threshold 

nmsig-internalMACRcvErrorThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  internalMACRcvErrorThreshold 

REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  : :=  {as  defined  in  ISO  Doc  X) 

internalMACRcvErrorThreshold  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  internal  MAC  receive  error  rate.  This  rate  is  defined  as 
the  number  of  internal  MAC  receive  errors  detected  per  second. 

A communication  alarm  notification  is  emitted  when  the  internal 
MAC  receive  error  rate  exceeds  the  threshold  value. 
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A. 6. 40.  NMSIG  Internal  MAG  Rev  Error  Counter 

nms ig- internalMACRcvErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  internalMACRcvErrorCounter 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  (as  defined  in  ISO  Doc  X) 

internalMACRcvErrorCounter  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  internal  MAC  receive 
errors  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV 
resource . 


A. 6. 41.  NMSIG  Internal  MAC  Xmt  Error  Threshold 

nmsig- internalMACXmtErrorThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  internalMACXmtErrorThreshold-behaviour 
REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  : (as  defined  in  ISO  Doc  X) 
internalMACXmtErrorThresho Id-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  internal  MAC  transmit  error  rate.  This  rate  is  defined  as 
the  number  of  internal  MAC  transmit  errors  detected  per  second. 
A communication  alarm  notification  is  emitted  when  the  internal 
MAC  transmit  error  rate  exceeds  the  threshold  value. 


A. 6. 42.  NMSIG  Late  Collision  Counter 

nmsig- lateCollisionsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  lateCollisionsCounter-behaviour 
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REGISTERED  AS  {nmsig-attr } 

Count  : :=  {as  defined  in  ISO  Doc  X) 
lateCo 11 is ionsCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  late  collisions  detected 
by  the  underlying  NMSIG  IEEE  802.3  XMT  resource. 


A. 6. 43.  NMSiG  Late  Collisions  Threshold 

nmsig- lateCollisionThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  lateCollisionThreshold-behaviour 
REGISTERED  AS  (nmsig-attr} 

GaugeThreshold  ; :=  {as  defined  in  ISO  Doc  X} 
lateCo 11 is ionThresho Id-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  late  collision  rate.  The  late  collision  rate  is  defined  as 
the  number  of  late  collision  PDUs  transmitted  divided  by  the 
total  number  of  PDUs  transmitted.  A communication  alarm 
notification  is  emitted  when  the  late  collision  rate  exceeds 
the  threshold  value. 


A. 6. 44.  NMSIG  Local  Network  Address 

nmsig- localNetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 
BEHAVIOUR  localNetworkAddress -behaviour 

REGISTERED  AS  (nmsig-attr) 

localNetworkAddress -behaviour  BEHAVIOUR 

DEFINED  AS 
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This  attribute  identifies  the  local  network  address  of  the 
transport  connection  (e.g.,  the  local  IP  address  for  TCP  or  the 
local  NSAP  for  OSI  TP) . 


A. 6. 45.  NMSIG  Local  Network  Addresses 

nmsig- localNetworkAddresses  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  LocalNetworkAddresses 
MATCHES  FOR  Set  Comparison,  Set  Intersection 
BEHAVIOUR  localNetworkAddresses -behaviour 

REGISTERED  AS  {nmsig-attr} 

LocalNetworkAddresses  : :=  SET  OF  OCTET  STRING 
localNetworkAddresses -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a set  of  local  network  addresses 
supported  by  a network  protocol  layer  entity. 


A. 6. 46.  NMSIG  Local  Transport  Addresses 

nmsig- localTransportAddresses  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  TransportAddresses 
MATCHES  FOR  Set  Comparison,  Set  Intersection 
BEHAVIOUR  localTransportAddresses -behaviour 

REGISTERED  AS  {nmsig-attr} 

TransportAddresses  : :=  SET  OF  SEQUENCE  ( 

transportConnectionEndpoint  OCTET  STRING, 
networkAddress  OCTET  STRING) 

localTransportAddresses -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  set  of  transport  addresses  that  a 
connection  oriented  transport  protocol  layer  entity  provides  to 
its  users.  A transport  address  consists  of  a transport 
connection  endpoint  and  a network  address. 


A. 6. 47.  NMSIG  Local  Transport  Connection  Endpoint 
nmsig- localTransportConnectionEndpoint  ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  localTransportConnectionEndpoint-behaviour 
REGISTERED  AS  {nmsig-attr ) 

localTransportConnectionEndpoint -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  identifies  the  local  transport  connection 
endpoint  (e.g.,  it  represents  the  source  port  for  TCP  or  the 
local  t-selector  for  OSI  TP). 


A.  6.48.  NMSIG  Location  Name 

nmsig- locationName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  AnyName 
MATCHES  FOR  Equality 
BEHAVIOUR  locationName -behaviour 

REGISTERED  AS  {nmsig-attr) 

AnyName  ; CHOICE  (dn  DistinguishedName , 

ps  PrintableString) 

locationName -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  name  of  a location  (e.g.,  Hilo 
Hawaii  USA) . 


A. 6. 49.  NMSIG  MAC  Address 

nmsig-macAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Octet String 

MATCHES  FOR  Equality 
BEHAVIOUR  macAddress -behaviour 

REGISTERED  AS  (nmsig-attr) 

macAddress -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a MAC  address. 
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A. 6. 50.  NMSIG  MAC  Port  Id 

nmsig-MAC-Portld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  mAC-PortID-behaviour 

REGISTERED  AS  (ninsig-attr } 

mAC-PortID-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  of  the  NMSIG  MAC 
Port  managed  object  class. 


A. 6. 51.  NMSIG  MAC  Port  In  Non-Unicast  Packets  Counter 

nms ig-MAC - Por t InNonUCas tPktsCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortInNonUCastPktsCounter-behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : {as  defined  in  ISO  Doc  X} 

mAC-PortInNonUCas tPktsCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  non-unicast  (i.e., 
subnet  broadcast  or  subnet  multicast)  packets  that  were 
received  at  the  MAC  port. 


A. 6. 52.  NMSIG  MAC  Port  In  Octet  Rate 

nms ig-MAC - Por tInOc te  tRate  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Gauge 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortInOctetRate 

REGISTERED  AS  (nmsig-attr) 

Gauge  ; :=  (as  defined  in  ISO  doc  X) 

mAC-PortInOcte tRate  BEHAVIOUR 
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DEFINED  AS 

This  attribute  specifies  the  rate  of  octets  arriving  at  the  MAC 
port  per  second. 


A. 6, 53.  NMSIG  MAC  Port  In  Octet  Rate  Threshold 

nmsig-MAC-PortInOctetRateThreshold  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  mAC-PortlnOctetRateThreshold 

REGISTERED  AS  (nmsig-attr ) 

GaugeThreshold  : :=  {as  defined  in  ISO  Doc  X) 

mAC-PortInOctetRateThreshold  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  in  octet  rate.  A communication  alarm  notification  is 
emitted  when  the  in  octet  rate  exceeds  the  threshold  value. 


A. 6. 54.  NMSIG  MAC  Port  In  Unicast  Packets  Counter 

nmsig-MAC-PortInUCastPktsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortInUCastPktsCounter 

REGISTERED  AS  {nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

mAC-PortInUCastPktsCounter  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  unicast  packets  received 
on  the  MAC  port. 


A. 6. 55.  NMSIG  MAC  Port  Out  Delay  Discarded  Packets  Cotanter 

nmsig-MAC-PortOutDelayDiscPktsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
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BEHAVIOUR  mAC-PortOutDelayDiscPktsCounter 
REGISTERED  AS  {niBsig-attr } 

Count  : {as  defined  in  ISO  Doc  X} 
inAC-PortOutDelayDiscPktsCounter  BEHAVIOUR 
DEFINED  AS 

Tliis  attribute  specifies  the  number  of  packets  that  were 
discarded  at  the  MAC  port  because  the  maximum  packet  hold  time 
was  exceeded. 


A. 6. 56.  MMSIG  MAC  Port  Out  Non-Unicast  Packets 

nmsig-MAC-PortOutNonUCastPktsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortOutNonUCastPktsCounter 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  (as  defined  in  ISO  Doc  X) 

inAC-PortOutNonUCastPktsCounter  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  non-unicast  packets  that 
were  sent  out  of  the  MAC  port. 


A, 6. 57.  NMSIG  MAC  Port  Out  Queue  Length 

nmsig-MAC-PortOutQLen  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortOutQLen 

REGISTERED  AS  (nmsig-attr) 

mAC-PortOutQLen  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  packets  that  are 
currently  queued  for  output  on  the  MAC  port. 
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A. 6. 58.  NMSIG  MAC  Port  Out  Unicast  Packets  Counter 

nmsig-MAC-PortOutUCastPktsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  mAC-PortOutUCastPktsCounter 

REGISTERED  AS  {nmsig-attr ) 

Count  : ;=  {as  defined  in  ISO  Doc  X) 

mAC-PortOutUCastPktsCounter  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  unicast  packets  that 
were  sent  out  of  this  MAC  port. 


A. 6. 59.  NMSIC  Max  Connections 

nrasig-maxConnections  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  maxConnect ions -behaviour 

REGISTERED  AS  (nmsig-attr) 

maxConnect ions -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  maximum  number  of  simultaneously 
open  transport  connections  allowed  by  the  transport  protocol 
layer  entity. 


A. 6. 60.  NMSIG  Max  Retransmissions 
nmsig-maxRe transmissions  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  maxRetransmiss ions -behaviour 

REGISTERED  AS  (nmsig-attr) 

maxRetransmiss ions -behaviour  BEHAVIOUR 

DEFINED  AS 
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This  attribute  specifies  the  maximum  number  of  times  a TPDU  is 
to  be  retransmitted  before  the  transport  connection  is  aborted. 


A. 6. 61.  NMSIG  Max  TPDU  Size 

nmsig-raaxTPDUSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  maxTPDUSize -behaviour 

REGISTERED  AS  {nmsig-attr) 

maxTPDUSize -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  maximum  TPDU  size  (in  terms  of 
octets)  that  can  be  handled  by  the  local  transport  protocol 
layer  entity. 

A. 6. 62.  NMSIG  Memory  Size 

nmsig-memorySize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  memorySize -behaviour 

REGISTERED  AS  {nmsig-attr} 

memorySize -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  amount  of  random  access  memory  (in 
kilobytes)  that  is  owned  by  a processing  entity.  (1  Kilobyte  = 
1024  bytes . ) 


A. 6. 63.  NMSIG  Multicast  Address  List 

nmsig-multicastAddressList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  AddressList 
MATCHES  FOR  Set  Comparison,  Set  Intersection 
BEHAVIOUR  multicastAddressList-behaviour 

REGISTERED  AS  {nmsig-attr} 

AddressList  : :=  SET  OF  OCTET  STRING 
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multicastAddressList -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a multicast  address  list. 


A. 6. 64.  NMSIG  Multicast  Forwarding  State 

nmsig-multicastForwardingState  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  State 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  multicastForwardingState -behaviour 

REGISTERED  AS  {nmsig-attr} 

State  ::=  ENUMERATED  {off  (0), 

on  ( 1 ) ) 

multicastForwardingState -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  whether  multicast  PDUs  are  being 
forwarded. 


A. 6. 65.  NMSIG  Multicast  PDUs  Rev  Cotmter 

nmsig-multicastPDUsRcvCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  multicastPDUsRcvCounter -behaviour 

REGISTERED  AS  {nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

multicastPDUsRcvCounter-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  multicast  PDUs  received 
ok  by  the  underlying  NMSIG  IEEE  802.3  RCV  resource. 


A. 6. 66.  NMSIG  Multicast  PDUs  Xmt  Counter 

nmsig-multicastPDUsXmtCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
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MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  multicastPDUsXmtCounter -behaviour 

REGISTERED  AS  {nmsig-attr } 

Count  ; :=  {as  defined  in  ISO  Doc  X} 

multicastPDUsXmtCounter -behaviour  BEHAVIOUR 


DEFINED  AS 

This  attribute  specifies  the  number  of  multicast  PDUs  which 
were  transmitted  ok  by  the  underlying  NMSIG  IEEE  802.3  XMT 
resource . 


A. 6. 67.  NMSIG  Multicast  Receive  State 

nmsig-multicastReceiveState  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  State 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  multicastReceiveSt ate -behaviour 

REGISTERED  AS  (nmsig-attr) 

State  : :=  ENUMERATED  (off  (0), 

on  ( 1 ) } 

multicastReceiveState -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  multicast  receive  state  of  the 
underlying  NMSIG  IEEE  802.3  RCV  resource. 


A. 6. 68.  NMSIG  Multiple  Collision  PDU  Counter 

nmsig-multipleCollisionPDUCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  multipleCollisionPDUCounter 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  (as  defined  in  ISO  Doc  X) 

multipleCollisionPDUCounter  BEHAVIOUR 

DEFINED  AS 
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This  attribute  specifies  the  number  of  multiple  collision  PDUs 
detected  by  the  underlying  NMSIG  IEEE  802.3  XMT  resource. 


A. 6. 69.  NMSIG  Network  Entity  Type 


nmsig-networkEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  NetworkEntityType 

MATCHES  FOR  Equality 

BEHAVIOUR  ne two rkEntityType -behaviour 


REGISTERED  AS  {nmsig-attr} 

NetworkEntityType  : :=  INTEGER  {other(O), 

oSI  CLNP  (1) , 

internet  IP  (2)}  (0..256) 

networkEntityType -behaviour  BEHAVIOUR 


DEFINED  AS 


This  attribute  specifies  the  type  of  the  network  protocol 
layer  entity. 


A.  6. 70.  NMSIG  Network  Id 

nmsig-networkid  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  networkid-behaviour 

REGISTERED  AS  (nrasig-attr) 

networkid-behaviour  BEHAVIOUR 

DEFINED  AS 

This  is  the  distinguishing  attribute  of  the  NMSIG  network 
managed  object  class. 


A. 6. 71.  NMSIG  Network  Purpose 

nmsig-networkPurpose  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  ne two rkPurpose -behaviour 

REGISTERED  AS  {nmsig-attr} 
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ne two rkPurpose -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  what  the  network  is  used  for  (e.g., 
manufacturing  control,  airline  reservation,  etc.) 


A. 6. 72.  NMSIG  NPDU  Time  To  Live 

nmsig-nPDUTimeToLive  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  nPDUTimeToLive -behaviour 

REGISTERED  AS  {nmsig-attr} 

nPDUTimeToLive -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  maximum  amount  of  time  (in  units 
of  10  ms)  that  an  NPDU  can  exist  in  the  network.  This 
attribute  is  used  to  limit  the  lifetime  of  NPDUs  during 
unstable  network  situations. 


A. 6. 73.  NMSIG  Octets  Retransmitted  Error  Counter 

nmsig-octetsRetransmittedErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  octetsRetransmitterErrorCounter -behaviour 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  (as  defined  in  ISO  Doc  X) 

octetsRetransmitterErrorCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  total  number  of  octets  that  were 
retransmitted. 


A. 6. 74.  NMSIG  OS  Info 
nmsig-osinfo  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Os Info 
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MATCHES  FOR  Set  Comparison,  Set  Intersection 
BEHAVIOUR  os Info -behaviour 


REGISTERED  AS  {nmsig-attr} 


Osinfo 


SET  OF  (CHOICE  {osName 
osSpec 


[0]  DistingishedName , 

[1]  ProductInfo}) 


ProductInfo 


SEQUENCE  {manufacturer 
productLabel 
release 
serialNumber 


Pr intableS tring , 
PrintableString, 
PrintableString , 
PrintableString) 


os Info -behaviour  BEHAVIOUR 


DEFINED  AS 

This  attribute  specifies  the  names  and  releases  of  operating 
systems  supported  by  the  processing  entity 


A. 6, 75.  NMSIG  Open  Cormections 

nmsig-openConnections  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  openConnect ions -behaviour 

REGISTERED  AS  {nmsig-attr) 

openConnections -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  currently  established 
transport  connections. 


A. 6. 76,  NMSIG  Out-Range  Tlrireshold 

runs  ig-  outRangeThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  outRangeThreshold-behaviour 

REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  : :=  {as  defined  in  ISO  Doc  X) 

outRangeThreshold-behaviour  BEHAVIOUR 
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DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  out-range  length  error  rate.  This  rate  is  defined  as  the 
number  of  PDUs  received  with  out-range  length  errors  divided  by 
the  total  number  of  PDUs  received.  A communication  alarm 
notification  is  emitted  when  the  out-range  length  error  rate 
exceeds  the  threshold  value. 


A. 6. 77,  NMSIG  Outgoing  Normal  Disconnect  Counter 

nmsig- outgo ingNormalDisconnectCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  outgoingNormalDisconnectCounter -behaviour 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  {as  defined  in  ISO  Doc  X) 

outgoingNormalDisconnectCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  outgoing  transport 
connections  that  were  disconnected  due  to  normal  reasons. 


A. 6. 78.  NMSIG  Packet  Loss  Rate 

nrnsig-packetLossRate  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Gauge 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  packetLossRate -behaviour 

REGISTERED  AS  (nmsig-attr) 

Gauge  : :=  (as  defined  in  ISO  Doc  X) 

packetLossRate -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  rate  of  packets  dropped  per 
second. 


A. 6. 79.  NMSIG  Packet  Loss  Rate  Threshold 
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nmsig-packetLossRateThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  packetLossRateThreshold 

REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  : :=  {as  defined  in  ISO  Doc  X) 

packetLossRateThreshold  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  packet  loss  rate.  A communication  alarm  notification  is 
emitted  when  the  packet  loss  rate  exceeds  the  threshold  value. 


A. 6. 80.  NMSIG  PDU  Too  Long  Threshold 

nms ig- PDUTooLongThresho Id  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 
BEHAVIOUR  pDUTooLongThreshold-behaviour 

REGISTERED  AS  (nmsig-attr) 

GaugeThreshold  ; :=  (as  defined  by  ISO  Doc  X) 

pDUTooLongThresho Id-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  "PDU  too  long"  error  rate.  The  PDU  too  long  error  rate  is 
defined  as  the  number  of  PDUs  received  that  were  too  long 
divided  by  the  total  number  of  PDUs  received.  A communication 
alarm  notification  is  emitted  when  the  "PDU  too  long"  error 
rate  exceeds  the  threshold  value. 


A. 6. 81.  NMSIG  PDUs  Aborted  Excessive  Collisions  Coianter 

nmsig-PDUsAbortedExcessiveCollisionsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsAbortedExcessiveCollisionsCounter-behaviour 

REGISTERED  AS  (nmsig-attr) 
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Count  : :=  {as  defined  in  ISO  Doc  X} 

pDUsAbortedExcessiveCollisionsCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  which  were  aborted 
by  the  underlying  NMSIG  IEEE  802.3  XMT  resource  due  to 
excessive  collisions. 


A. 6. 82.  NMSIG  PDUs  Aborted  Excessive  Collisions  Threshold 

runsig-PDUsAbortedExcessColThreshold  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GaugeThreshold 
MATCHES  FOR  Equality 

BEHAVIOUR  pDUsAbortedExcessColThresho Id-behaviour 
REGISTERED  AS  (nmsig-attr} 

GaugeThreshold  : :=  (as  defined  in  ISO  Doc  X) 
pDUsAbortedExcessColThreshold-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  a threshold  which  is  applied  against 
the  PDUs  aborted  due  to  excessive  collision  rate.  This  rate  is 
defined  as  the  number  of  PDUs  aborted  due  to  excessive 
collision  divided  by  the  total  number  of  PDUs  transmitted.  A 
communication  alarm  notification  is  emitted  when  the  PDUs 
aborted  due  to  excessive  collision  rate  exceeds  the  threshold 
value . 


A. 6. 83.  NMSIG  PDUs  Alignment  Error  Counter 

nmsig-PDUsAlignmentErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsAlignmentErrorCounter -behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

pDUsAlignmentErrorCounter -behaviour  BEHAVIOUR 

DEFINED  AS 
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This  attribute  specifies  the  number  of  PDUs  with  an  alignment 
error  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV  resource. 


A. 6. 84.  NMSIG  PDUs  Excessive  Deferral  Counter 
nmsig-PDUsExcessiveDeferralCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsExcessiveDeferralCounter -behaviour 

REGISTERED  AS  {nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X} 

pDUsExcessiveDeferralCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  for  which  the 
underlying  NMSIG  IEEE  802.3  XMT  resource  detected  excessive 
deferral . 


A. 6. 85.  NMSIG  PDUs  Discarded  Counter 

nmsig-PDUsDiscardedCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsDiscardedCounter -behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  (as  defined  in  ISO  Doc  X) 

pDUsDiscardedCounter-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  that  were  discarded 
by  a network  protocol  layer  entity. 


A. 6. 86.  NMSIG  PDUs  FCS  Error  Counter 

nmsig-PDUsFCSErrorCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsFCSErrorCounter -behaviour 
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REGISTERED  AS  {nmsig-attr ) 

Count  : :=  {as  defined  in  ISO  Doc  X) 
pDUsFCSErrorCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  with  an  FCS  error 
detected  by  the  underlying  NMSIG  IEEE  802.3  RCV  resource. 


A. 6. 87.  NMSIG  PDUs  Forwarded  Counter 

nms ig- PDUsForwardedCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsForwardedCounter -behaviour 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  {as  defined  in  ISO  Doc  X) 

pDUsForwardedCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  forwarded  by  a 
network  protocol  layer  entity. 


A. 6. 88.  NMSIG  PDUs  In-Range  Length  Error  Counter 

nms ig- PDUs InRangeLengthErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsInRangeLengthErrorCounter-behaviour 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  {as  defined  in  ISO  Doc  X} 

pDUs InRangeLengthErrorCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  with  an  in-range 
length  error  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV 
resource . 


A. 6. 89.  NMSIG  PDUs  Lost  Internal  MAC  Xmt  Error  Counter 
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nmsig-PDUsLostlnternalMACXmtErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsLostInternalMACXmtErrorCounter-behaviour 

REGISTERED  AS  {nmsig-attr ) 

Count  : :=  {as  defined  in  ISO  Doc  X} 

pDUsLostInternalMACXmtErrorCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  which  were  lost  by 
the  underlying  NMSIG  IEEE  802.3  XMT  resource  due  to  an  internal 
MAC  transmit  error. 


A. 6. 90.  NMSIG  PDUs  Out-Range  Error  Counter 

nmsig-PDUsOutRangeLengthErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsOutRangeLengthErrorCounter -behaviour 

REGISTERED  AS  {nmsig-attr) 

Gount  : :=  {as  defined  in  ISO  Doc  X) 

pDUsOutRangeLengthErrorCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  with  an  out-range 
length  error  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV 
resource . 


A. 6. 91.  NMSIG  PDUs  Reassemble  Fail  Counter 

nmsig-PDUsReasmblFailCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsReasmblFailCounter -behaviour 

REGISTERED  AS  {nmsig-attr) 

Gount  : :=  {as  defined  in  ISO  Doc  X) 
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pDUsReasmblFailCounter-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  that  could  not  be 
reassembled  successfully  by  a network  protocol  layer  entity. 


A. 6. 92.  NMSIG  PDUs  Reassembled  OK  Counter 

nrasig-PDUsReasmbldOKCounter  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  Count 
liATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsReasmbldOKCounter -behaviour 

REGISTERED  AS  (nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

pDUsReasmbldOKCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  that  were 
reassembled  successfully  by  a network  protocol  layer  entity. 


A. 6. 93.  NMSIG  PDUs  Too  Long  Error  Counter 

nmsig-PDUsTooLongErrorCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  pDUsTooLongErrorCounter -behaviour 

REGISTERED  AS  {nmsig-attr) 

Count  : :=  {as  defined  in  ISO  Doc  X) 

pDUsTooLongErrorCounter-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  PDUs  with  a "PDU  too 
long"  error  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV 
resource . 


A. 6. 94.  NMSIG  Peripheral  Names 
nmsig-peripheralNames  ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX  PeripheralNames 
MATCHES  FOR  Set  Comparison,  Set  Intersection 
BEHAVIOUR  per ipheralNames -behaviour 

REGISTERED  AS  {nmsig-attr ) 

PeripheralNames  : :=  SET  OF  AnyName 

AnyName  : CHOICE  {dn  DistinguishedName , 

ps  PrintableString) 

PeripheralNames -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  names  of  auxiliary  devices. 


A. 6. 95.  NMSIG  Product  Info 

nmsig-productinfo  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  ProductInfo 
MATCHES  FOR  Equality 
BEHAVIOUR  prod’ll' tinfo- behaviour 

REGISTERED  AS  (nmsig-attr) 

ProductInfo  : :=  SEQUENCE  (manufacturer 

productLabel 
release 
serialNumber 

ProductInfo -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  product  information  of  the  underlying 
resource . 


PrintableString , 
Printable String, 
PrintableString, 
PrintableString) 


A. 6. 96.  NMSIG  Promiscuous  Receive  State 

nmsig-promiscuousReceiveState  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  State 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  promiscuousReceiveState -behaviour 

REGISTERED  AS  (nmsig-attr) 


State  ENUMERATED  (off  (0) , 

on  ( 1 ) ) 
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promiscuousReceiveState "behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  promiscuous  receive  state  of  the 
underlying  NMSIG  IEEE  802.3  RCV  resource. 


A, 6,97.  NMSIG  Remote  Network  Address 

nmsig-remoteNetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 
BEHAVIOUR  remo teNe two rkAddress -behaviour 

REGISTERED  AS  {nmsig-attr} 

remoteNetworkAddress -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  identifies  the  remote  network  address  of  the 
transport  connection  (e.g.,  it  represents  the  remote  IP  address 
for  TCP  or  the  remote  NSAP  for  OS I TP) . 


A. 6, 98.  NMSIG  Remote  Transport  Connection  Endpoint 

nmsig-ramoteTransportCormectionEndpoint  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  remoteTransportConnectionEndpoint-behaviour 
REGISTERED  AS  {nmsig-attr] 

remo teTransportConnectionEndpoint -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  identifies  the  remote  transport  connection 
endpoint  ( It  represents  the  destination  port  for  TCP  or  the 
remote  t-selector  for  OSI  TP). 


A. 6. 99.  NMSIG  Retrarusmission  Timer  Initial  Value 

nrasig-retransmissionTimerIriitialValue  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  INTEGER 
MATCHES  FOR  Equality,  Ordering 
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BEHAVIOUR  re transmiss ionTimer Ini tialValue -behaviour 
REGISTERED  AS  {nmsig-attr ) 

retransmissionTimerInitialValue -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  initial  value  (in  1/lOOths  of  a 
second)  of  the  retransmission  timer  used  by  a transport 
connection. 


A. 6. 100.  NMSIG  Single  Collision  PDUs  Counter 

nmsig-singleCollisionPDUsCounter  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  Count 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  singleCollisionPDUsCounter-behaviour 

REGISTERED  AS  {nmsig-attr} 

Count  : :=  {as  defined  in  ISO  Doc  X} 

singleCo 11 is ionPDUsCounter -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  number  of  single  collision  PDUs 
detected  by  the  underlying  NMSIG  IEEE  802.3  XMT  resource. 


A. 6. 101.  NMSIG  Source  Address  Last  Alignment  Error  FDU 

nmsig-sourceAddrLastAllgnraentErrorPDU  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  sourceAddrLastAlignmentErrorPDU-behaviour 
REGISTERED  AS  {nmsig-attr} 

sourceAddrLastAlignmentErrorPDU-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  source  address  of  the  last 
alignment  error  PDU  detected  by  the  underlying  NMSIG  IEEE  802.3 
RCV  resource. 
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A. 6. 102.  NMSIG  Source  Address  Last  FCS  Error  PDU 

nmsig-sourceAddrLastFCSErrorPDU  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  sourceAddrLastFCSErrorPDU-behaviour 
REGISTERED  AS  {nmsig-attr ) 

sourceAddrLastFCSErrorPDU-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  source  address  of  the  last  FCS 
error  PDU  detected  by  the  underlying  NMSIG  IEEE  802.3  RCV 
resource . 


A. 6. 103.  NMSIG  Source  Address  Last  In-Range  Length  Error  PDU 

nmsig-sourceAddrLastlnRangeLengthErrorPDU  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  sourceAddrLastInRangeLengthErrorPDU-behaviour 
REGISTERED  AS  {nmsig-attr) 

sourceAddrLastInRangeLengthErrorPDU -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  source  address  of  the  last 
in-range  length  error  PDU  detected  by  the  underlying  NMSIG  IEEE 
802.3  RCV  resource. 


A. 6. 104,  NMSIG  Source  Address  Last  Out-Range  Length  Error  PDU 

runs ig-sourceAddrLastOutRangeLengthError PDU  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  sourceAddrLastOutRangeLengthErrcrPDU-behaviour 
REGISTERED  AS  (nmsig-attr) 

sourceAddrLastOutRangeLengthErrorPDU-behaviour  BEHAVIOUR 
DEFINED  AS 
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This  attribute  specifies  the  source  address  of  the  last 
out-range  length  error  PDU  detected  by  the  underlying  NMSIG 
IEEE  802.3  RCV  resource. 


A. 6. 105.  NMSIG  Source  Address  La.st  Too  Long  Error  PDU 

nmsig-sourceAddrLastTooLongErrorPDU  ATTRIBUTE 
WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 
BEHAVIOUR  sourceAddrLastTooLongErrorPDU 

REGISTERED  AS  (nmsig-attr) 

sourceAddrLastOutRangeLengthErrorPDU-behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  source  address  of  the  last  "PDU 
too  long"  error  PDU  detected  by  the  underlying  NMSIG  IEEE  802.3 
RCV  resource. 


A. 6. 106.  NMSIG  System  Id 

nmsig-systemld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  systemid-behaviour 

REGISTERED  AS  {ninsig-attr } 

systemid-behaviour  BEHAVIOUR 

DEFINED  AS 

This  is  the  distinguishing  attribute  of  the  NMSIG  computer 
system  managed  object  class. 


A. 6. 107.  NMSIG  System  Time 

nmsig- systemTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  GeneralizedTime 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  systemTime -behaviour 

REGISTERED  AS  (nmsig-attr) 

systemTime -behaviour  BEHAVIOUR 
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DEFINED  AS 

This  attribute  specifies  the  current  time  clocked  at  the 
computer  system. 


A.  6. 108.  NMSIG  Transport  Connection  Id 

nmsig- transportConnectionId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  transportConnectionId-behaviour 

REGISTERED  AS  {nmsig-attr) 

transportConnectionId-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  for  the  managed 
object  class  transportConnection. 


A. 6. 109.  NMSIG  Transport  Connection  Profile  Id 
nmsig- transportConnectionProfileld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 

BEHAVIOUR  transportConnectionProf ileld-behaviour 
REGISTERED  AS  {nmsig-attr) 

transportConnectionProf ileld-behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  is  the  distinguishing  attribute  for  the  managed 
object  class  nmsig- transportConnectionProf ile , 


A. 6, 110.  NMSIG  Transport  Connection  Reference 

nmsig- transportConnectionReference  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  OCTET  STRING 
MATCHES  FOR  Equality 

BEHAVIOUR  transportConnectionReference -behaviour 
REGISTERED  AS  {nmsig-attr} 

transportConnectionReference -behaviour  BEHAVIOUR 
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DEFINED  AS 

This  attribute  identifies  the  local  transport  connection 
reference  that  is  established  by  the  two  transport  connection 
endpoints  (e.g.,  the  local  socket  number  for  TCP  or  the  local 
connection  reference  for  OSI) . 


A. 6, 111.  NMSIG  Transport  Entity  Type 

nmsig- transportEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  TransportEntityType 
MATCHES  FOR  Equality 

BEHAVIOUR  transportEntityType -behaviour 

REGISTERED  AS  { nmsig- at tr ) 

TransportEntityType  : :=  INTEGER  {other(O), 

oSI  TP  (1), 
tCP  (2), 

sNA  (3) } (0. .256) 

transportEntityType -behaviour  BEHAVIOUR 
DEFINED  AS 

This  attribute  specifies  the  type  of  the  transport  protocol 
layer  entity. 


A. 6. 112.  NMSIG  User  Friendly  Label 

nmsig-userFriendlyLabel  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  PrintableString 
MATCHES  FOR  Equality 
BEHAVIOUR  userFriendlyLabel -behaviour 

REGISTERED  AS  {nmsig-attr} 

userFr iendlyLabe 1 -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  a user  friendly  name. 


A. 6. 113.  NMSIG  Vendor  Name 
nmsig- vendorName  ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX  AnyName 
MATCHES  FOR  Equality 
BEHAVIOUR  vendorNarae -behaviour 

REGISTERED  AS  {nmsig-attr) 

AnyName  : :=  CHOICE  {dn  DistinguishedName , 

ps  PrintableString) 

vendorName -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribute  specifies  the  name  of  a vendor. 


A. 6. 114.  NMSIG  Xmt  State 

nmsig-XmtState  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  EnableState 
MATCHES  FOR  Equality,  Ordering 
BEHAVIOUR  xratState -behaviour 

REGISTERED  AS  {nmsig-attr) 

EnableState  ; :=  ENUMERATED  {disable  (0), 

enable  (1)) 


xmtS tat e -behaviour  BEHAVIOUR 

DEFINED  AS 

This  attribxite  specifies  whether  the  transmitting  capability  of 
the  unserlying  IEEE  802,3  resource  is  enabled  or  not.  The 
'enabled'  and  'disabled'  values  of  this  attribute  correspond  to 
the  'enabled'  and  'disabled'  values  of  the  OperationalState 
attribute  of  the  IEEE  802.3  XMT  managed  object  class.  (This 
attribute  was  introduced  as  a GET-REPLACE  attribute  which  can 
be  used  by  management  to  enable  or  disable  the  transmitting 
capability  of  the  underlying  IEEE  802.3  resource.) 


A. 6. 115.  Object  Class 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  attribute. 


A. 6. 116.  Octets  Received  Counter 

Refer  to  [ISO  Doc  X]  for  the  definition  of  this  attribute. 
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A. 6. 117. 

Octets  Sent  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6. 118. 

Operational  State 

Refer  to 

[ISO  Doc  x]  for  the  definition  of  this  attribute 

A. 6. 119. 

Outgoing  Connection  Reject  Error  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6. 120. 

Outgoing  Connections  Request  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6. 121. 

Outgoing  Disconnect  Error  Counter 

Refer  to 

[ISO  Doc  Xj  for  the  definition  of  this  attribute 

A. 6. 122. 

Outgoing  Temporal  Error  Cosinter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6. 123. 

PDUs  Received  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6 . 124. 

PDUs  Sent  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 

A. 6. 125. 

PDUs  Retransmitted  Error  Counter 

Refer  to 

[ISO  Doc  X]  for  the  definition  of  this  attribute 
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A.  7.  ACTIONS 

This  section  provides  definitions  of  actions  supported  by  managed 
object  classes  defined  by  the  OSI  MIB  Working  Group.  Action 
definitions  for  managed  object  classes  defined  by  other  groups  can  be 
found  in  the  document  referenced  under  the  managed  object  class 
definition  in  section  3. 

A. 7.1.  MiSIG  Execute  Self  Test 

nmsig-executeSelfTest  ACTION 

ACTION  BEEA.VIOUR  selfTestBehaviour 
WITH  RESULT  SYNTAX  SelfTestResult 

REGISTERED  AS  (nmsig-action) 

selfTestBehaviour  BEHAVIOUR 

DEFINED  AS 

This  action  requests  a self  test  sequence  be  executed  on  the 
referenced  managed  object  instance.  This  action  is  always 
confirmed.  The  confirmation  contains  the  operational  state  of 
the  managed  object  under  test  follov/ing  test  completion,  and 
optionally  indicates  the  success  or  failure  of  the  self  test. 


SelfTestResult  : :=  SEQUENCE 

{ 

operationalState  OperationalState , 
testResult  BOOLEAN  OPTIONAL 

) 
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A. 8.  NOTIFICATIONS 

This  section  provides  definitions  of  notifications  emitted  by  managed 
object  classes  defined  by  the  OSI  MIB  Working  Group.  Notification 
definitions  for  managed  object  classes  defined  by  other  groups  can  be 
found  in  the  document  referenced  under  the  managed  object  class 
definition  in  section  3. 

A. 8.1.  Attribute  Change  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 


A. 8. 2.  Communication  Alarm  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 


A. 8. 3.  Equipment  Alarm  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 


A. 8. 4.  Environmental  Alarm  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 


A. 8. 5.  NMSIG  Counter  Wrap  Unconfirmed 

nmsig-counterWrapUnconf irmed  NOTIFICATION 

BEHAVIOUR  counterWrap -behaviour 
WITH  DATA  SYNTAX  Wrap Info 

REGISTERED  AS  (notification) 

counterWrap -behaviour  BEHAVIOUR 

DEFINED  AS 

This  notification  indicates  that  a counter  has  wrapped. 

Wrapinfo  ; :=  Attribute  { --  attribute  ID  and  value  of  counter 

attribute  that  wrapped  ) 


A. 8. 6.  Object  Creation  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 
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A. 8. 7.  Object  Deletion  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 

A. 8. 8.  Processing  Error  Alarm  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 

A. 8. 9.  Relationship  Change  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 

A. 8. 10.  State  Change  Unconfirmed 

Refer  to  [ISO  Doc  x]  for  the  definition  of  this  notification. 

A. 9.  REFERENCES 

This  section  lists  the  names  of  documents  that  were  referenced  in  the 
earlier  sections. 
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19.  REMOTE  DATABASE  ACCESS 


19.1  INTRODUCTION 


Remote  Database  Access  (RDA)  specifies  the  communications  service 
and  protocol  for  accessing  the  capabilities  of  a database  server 
from  a client  application.  Figure  19.1  depicts  RDA's  placement 
within  the  application  layer  and  its  relationship  to  supporting 
OSI  protocols: 


+ + 

I 1 

I Remote  Database  Access  | 

I I 

+ + + 

I I I 

I ASCE  I TP  I 

I !■  H 1- 

I I 1 OCR  I 

+ + + + 

i I 

I Presentation  1 

I I 

4- + 

i I 

I Session  | 

! I 

-| 

Figure  19.1.  Placement  of  RDA  within  the  Application  Layer. 

This  is  an  implementation  agreement  for  RDA  developed  by  the 
Implementors  Workshop  sponsored  by  the  U.S.  National  Institute  of 
Standards  and  Technology.  This  document  addresses  both  the  RDA 
generic  model,  service,  and  protocol,  as  well  as  the  SQL 
Specialization,  ISO  9579  parts  1 and  2,  respectively.  It  is  the 
intent  of  the  workshop  to  expand  this  agreement  to  include  other 
parts  of  9579  as  they  are  developed. 


19.2  SCOPE 


This  implementation  agreement  addresses  remote  database 
Interaction  between  a database  server  and  a client 
application.  The  database  server  is  an  open  system  that 
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provides  database  storage  facilities  and  supplies  database 
processing  services  to  clients  at  other  open  systems. 

The  RDA  communications  service  provides  the  protocol  for  RDA 
client  interaction  with  an  RDA  server.  The  RDA  client 
initiates  an  RDA  dialogue  and  requests  RDA  operations  to  be 
performed  by  the  RDA  server  on  behalf  of  a client 
applications.  The  RDA  server,  located  within  the  database 
server,  provides  database  services  to  RDA  clients. 

More  specifically,  this  document  describes  implementation 
agreements  in  the  following  areas: 

1.  the  RDA  generic  model,  service,  and  protocol, 

2.  the  RDA  SQL  Specialization,  and 

3.  SQL  language  restrictions. 

19,3  REFERENCES 


The  following  documents  contain  provisions  which,  through 
reference  in  this  text,  constitute  provisions  of  this 
International  Standardized  Profile.  At  the  time  of 
publication,  the  additions  Indicated  were  valid.  All 
documents  are  subject  to  revision,  and  parties  to  agreements 
based  on  this  International  Standardized  Profile  are  warned 
against  automatically  applying  any  more  recent  additions  of 
the  documents  listed  below,  since  the  nature  of  references 
made  by  ISPs  to  such  documents  is  that  they  may  be  specific  to 
a particular  addition.  Members  of  lEC  and  ISO  maintain 
registers  of  currently  valid  International  Standards  and  ISPs, 
and  CCITT  maintains  published  additions  of  its  current 
recommendations . 

ISO  9579-1  Information  Processing  Systems  - Open  Systems 
Interconnection  - Remote  Database  Access  - Part  1:  Generic 
Model,  Service,  and  Protocol 

ISO  9579-2  Information  Processing  Systems  - Open  Systems 
Interconnection  - Remote  Database  Access  - Part  2:  SQL 
Specialization 

ISO/IEC/TRlOOOO-1 : 1990(E)  Information  Technology  - Framework 
and  Taxonomy  of  International  Standardized  Profiles  - Part  1: 
Framework 

NoterWork  on  ISO  9579  is  ongoing. 
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19.4  DEFINITIONS 

19.5  ABBREVIATIONS 

19.6  RDA  DIALOGUE  STATE  MODEL  AGREEMENTS 

19.7  GENERIC  RDA  AGREEMENTS 

19 ■ 7 . IFunctional  Units 

19 . 7 . 20ptional  Negotiable  Facilities 

19 ■ 7 ■ 2 ■ lOpen/Close  Within  Transaction 

19.7. 3Services 

19.7.3. iR-BeginPialogue 

19 . 7 . 3 . 1 . iQptional  Parameters 

19 . 7 . 3 . 1 . 2Paranieter  Restrictions 

19.7.3. 2R-EndDialogue 

19.7.3. 3R-Open 

19.7.3.4R-Close 

19.7.3. 5R-Execute 
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19.7.3.6R-Define 

19.7.3. 7R- Invoke 

19.7.3.8R-DrQT) 

19.7.3. 9R-BeginTransaction 

19.7.3. IQR-Commi r 

19.7.3. 1 IR- Rollback 

19.7.3. 12R-Status 

19.7.3. 13Cancel 

19.8  SQL  SPECIALIZATION  AGREEMENTS 

19 . 8 . IFunctlonal  Units 

19 . 8 . 20ptional  Facilites 

19.8. 3Services 

19.8. 4SQL  Language  Agreements 

19.8.4. iLanguage/Protocal  Mapping 

19 . 8 . 4 . 2Implementor  Defined  Items 
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19.8.4.3SOL  Functional  Restrictions 


19.8.4.4SQL  State  and  Error  Messages 

19.8. SConformance  Requirements 


19  ■ 8 ■ SRecoHimended  Practices 
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20.  MANUFACTURING  MESSAGE  SPECIFICATION  (MMS) 

20.1  INTRODUCTION 


This  section  defines  Implementors  Agreements  based  on  ISO 
Manufacturing  Message  Specification  (MMS),  as  defined  in  ISO  9506. 
This  International  Standard  has  two  parts.  Part  1 of  the  IS 
defines  the  Virtual  Manufacturing  Device  (VMD)  as  well  as  defining 
the  services,  and  Part  2 defines  the  Protocol.  Future  parts  may 
define  companion  standards. 

MMS,  as  described  in  the  IS,  is  based  on  the  following  ISO 
documents:  ACSE  Service  and  Protocol  (ISO  8649,  ISO  8650), 
Presentation  Service  and  Protocol  (ISO  8822,  ISO  8823),  ASN.l 
Abstract  Syntax  Notation  and  Basic  Encoding  Rules  (ISO  8824,  ISO 
8825),  and  Session  Service  and  Protocol  (ISO  8326,  ISO  8327). 

These  services  and  protocols  are  defined  architecturally  in  the 
OSI  Reference  Model  (ISO  7498).  These  Agreements  provide  detailed 
guidance  for  the  implementor,  and  eliminate  ambiguities  in 
interpretations . 

The  agreements  can  be  used  over  any  T-Profile  (see  ISO  DTR  10000) 
specifying  the  OSI  connection-mode  transport  service.  In 
addition,  these  MMS  agreements  can  be  used  over  the  Transport 
profiles  used  in  support  of  MAP  (Manufacturing  Automation 
Protocol)  or  TOP  (Technical  and  Office  Protocols). 


20.1. IReferences 

Application  Layer  - MMS 

ISO  9506-1:  1988Manufacturing  Message  Specification  Service 
Definition 

ISO  9506-2:  1988Manufacturing  Message  Specification  Protocol 
Specification 


20.2  SCOPE  AND  FIELD  OF  APPLICATION 

There  will  be  a phased  grouping  of  implementation  agreements. 

These  agreements  will  be  based  on  selected  subsets  of  MMS  services 
as  defined  in  ISO  9506-1.  Agreements  will  be  defined  in  phases 
which  will  be  added  as  needed. 
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20.2.1  Phase  I Agreements 

These  agreements  will  be  implementation  agreements  pertaining  to 
the  services  as  specified  as  table  20.1. 

Table  20.1.  Phase  I Services 


Initiate 

Conclude 

Reject 

Abort 

Status 

GetNameList 

Identify 

UnsolicitedStatus 

GetCapabilityList 

InitiateDownloadSequence 
DownloadSegment 
TerminateDownloadSequence 
InitiateUploadSequence 
Up loads egment 
TerminateUploadSequence 
DeleteDomain 
GetDomainAt tributes 

Read 

Write 

InformationReport 
GetVariableAccessAt tributes 

Input 

Output 

CreateProgramInvocation 

DeleteProgramInvocation 

Start 

Stop 

Resume 

Reset 

Kill 

GetProgramInvocationAt tributes 
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Phase  1 is  in  progress. 


20.4  ERRATA 

None  at  time  of  publication. 


20.5  SPECIFIC  SERVICE  AGREEMENTS 


20.5. llnitiate 


20.5.1.1Max  Serv  Outstanding 

oAn  MMS  Implementation  which  intends  to  conform  only  with  the 
Client  Conformance  Requirements  for  Requester  CBBs  shall: 

1.  propose  1 or  greater  for  the  value  of  the  Proposed  Max  Seirv 
Outstanding  Calling  parameter  in  the  Initiate  service  when  initiating 
the  application  association  (calling) . 

2. offer  1 or  greater  for  the  value  of  the  Negotiated  Max  Serv 
Outstanding  Called  parameter  in  the  Initiate  service  when  receiving 
the  application  association  initiation  (called) . 

oAn  MMS  Implementation  which  intends  to  conform  to  one  or 
more  Server  Conformance  Requirements  for  Responder  CBBs  shall: 

1. propose  1 or  greater  for  the  value  of  the  Proposed  Max  Serv 
Outstanding  Called  parameter  in  the  Initiate  service  when  initiating 
the  application  association  (calling) . 

2. offer  1 or  greater  for  the  value  of  the  Negotiated  Max  Serv 
Outstanding  Calling  parameter  in  the  Initiate  service  when  receiving 
the  application  association  initiation  (called) . 


20 ■ 5 . 1 . 2Version  Number 

oThe  value  of  zero,  for  the  proposed  Version  Number  in  the 
Initiate  request  and  the  negotiated  Version  Number  in  the  Initiate 
response  service  primitives,  is  reserved  to  enable  interoperability 
with  existing  DIS  based  implementations. 
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Tutorial : 

There  is  an  installed  base  of  real  DIS  9506  based 
implementations.  Providing  support  for  application  connectivity  to 
both  DIS  and  IS  is  desired  as  a migration  strategy.  It  was  found  that 
the  Abstract  S3mtax  name  object  identifiers  of  both  DIS  and  IS  were 
identical.  Therefore,  the  use  of  Version  0 allows  differentiation 
between  an  IS  and  a DIS  based  implementation. 

NoterThe  value  of  zero  is  a valid  value  for  these  parameters 
in  the  DIS  and  not  in  the  IS. 


20 . 5 . 1 . 3Minimum  Supported  PDU  Size 

MMS  implementations  must  be  able  to  parse  and  process  64 
octets  of  MMS  pdu  as  they  would  be  encoded  in  ASN.l  Basic 
Encoding  Rules.  However,  it  is  recommended  that  512  be 
supported. 


20.5.1.4Max  Supported  PDU  Size 

The  max_mms_pdu_size  is  defined  as  the  maximum  number  of 
octets  in  an  MMS  pdu  encoded  using  the  negotiated  transfer 
syntax . This  size  shall  apply  to  all  MMS  PDU's  with  the 
exception  of  the  initiate-Request  PDU,  initiate-Response 
PDU,  and  initiate-Error  PDU.  The  max_mms_pdu_size  shall  be 
negotiated  during  connection  initiation  using  the  Local 
Detail  Calling  and  Local  Detail  Called  parameters  of  the  MMS 
initiate  service. 

The  semantics  of  these  parameters  follows: 

Local  Detail  Calling 

The  local  detail  calling  parameter  in  the  initiate  request 
primitive  shall  specify  the  max_mms_pdu_size  guaranteed  to 
be  supported  by  the  calling  MMS -user.  The  local  detail 
calling  parameter  in  the  initiate  indication  primitive  shall 
specify  the  max_mms_pdu_size  guaranteed  to  be  supported  by 
both  the  Calling  MMS-user  and  the  MMS-provider . This  shall 
be  less  than  or  equal  to  the  max_mms_pdu_size  specified  in 
the  initiate  request  primitive. 

If  the  local  detailcalling  parameter  is  absent  from  the 
request  primitive,  then  the  calling  MMS-user  guarantees 
support  for  an  unlimited  raax_mms_pdu_size . If  the  MMS- 
provider  is  not  able  to  make  this  guarantee,  then  this 
parameter  shall  be  supplied  in  the  indication  primitive  with 
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the  largest  non-zero  value  which  the  MMS-provider  is  capable 
of  supporting.  Otherwise,  it  shall  be  absent  from  the 
indication  primitive,  indicating  that  the  Calling  MMS-user 
and  the  MMS-provider  are  prepared  to  support  an  unbounded 
max_mms_pdu_size . 

If  present  in  the  request  or  indication  primitives,  the 
local_detail_calling  parameter  shall  not  be  less  than  64. 

Local  Detail  Called 

The  local  detail  called  parameter  in  the  initiate  response 
shall  specify  the  negotiated  max_mms__pdu_size  for  the 
application  association. 

If  the  local  detail  calling  parameter  was  omitted  in  the 

indication  primitive,  then  the  local_detail_called 
parameter : 

1. may  be  omitted  from  the  response  primitive,  indicating  that 
the  calling  MMS-user,  the  MMS-provider  and  the  Called  MMS-user  are 
prepared  to  support  an  unbounded  max_mms_pdu_size , or, 

2.  may  be  specified  in  the  response  primitive,  indicating  a 
requirement  to  support  the  specified  value  for  max_mms_pdu_size . 

If  the  local  detail  calling  parameter  was  included  in  the 

indication  primitive,  then  the  value  of  this  parameter  shall 
be  less  than  or  equal  to  the  value  of  the  local  detail 
calling  parameter  of  the  indication  primitive. 

If  present  in  the  response  or  confirm  primitives,  the  local 
detail  called  parameter  shall  not  be  less  than  64. 

The  negotiated  max_mms_pdu_size  shall  be  applied  as  follows: 
Any  received  MMSpdu  which  is  less  than  or  equal  to  the 

negotiated  max_mms_pdu_size  shall  be  properly  parsed  and 
processed. 

When  rejecting  an  MMS-pdu  because  it  exceeds  the  negotiated 
max_mms_pdu_size , an  MMS  implementation  shall  use  a pdu  type 
of  pdu_error  and  a reject  code  of  invalid_pdu  in  the 
resulting  reject  PDU. 

An  MMS  implementation  shall  not  send  an  MMSpdu  whose  size 
exceeds  the  negotiated  max_mms_pdu_size . 

If  an  MMS  implementation  is  unable  to  send  a service 
response  because  the  response  would  exceed  the  max_mms_pdu_size , then 
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it  shall  return  a Service  response  (-)  with  an  error  class  of  SERVICE 
and  an  error  code  of  OTHER. 


20.5.1.5Ne£otiation  of  MMS  Abstract  Syntaxes 

On  initiate  response,  the  MMS  responder  shall  not  accept 
more  than  one  presentation  context  derived  from  an  MMS 
abstract  S3mtax  (in  this  context,  only  the  core  MliS  abstract 
syntax  and  the  Companion  Standard  defined  abstract  s3nitaxes, 
are  considered  MMS  abstract  syntaxes) . 


20 ■ 5 . 2Scattered  Access 


It  is  strongly  recommended  that  for  services  which  use  variable 
access,  a Variable  List  Name  or  List  of  Variable  be  used 
Instead  of  Scattered  Access. 

No  implementations  shall  be  required  to  propose  or  accept  the 
VSCA  Parameter  CBB. 


20 ■ 5 . 3Scattered  Access 


It  is  stongly  recommended  for  services  which  use  floating  point 
types  or  values,  that  the  MMS  choice  of  floating-point  in  the 
Data  and  Type  specification  productions  be  used  instead  of  the 
real  choice. 

No  implementations  shall  be  required  to  propose  or  accept  the 
REAL  parameter  CBB. 

20.5.4Start  Stop, Resume,  and  Reset  Services 

A ProgramInvocationState  of  non-existent  shall  be  returned  in  a 
Result(-)  when  a request  to  Start,  Stop,  Resume,  or  Reset  a 
non-existent  Program  Invocation  is  received. 


20.5. SFileName 

Restrictions  for  the  use  of  the  type  FileName  in  the  MMS 
Abstract  S3mtax  are  specified  in  section  9.9.1. 
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20 . 5 ■ 6Doinain  Management  Agreements 


20.5.6.1List  of  Capabilities 

Only  one  capability  will  be  described  in  each  Visible  String 
of  the  SEQUENCE  OF. 


20 . 5 ■ 6 . 2Initiate  Download  Sequence  Service 

Tlie  List  of  Capability  parameter  will  follow  the  limitations 
of  20.5.6.1. 

The  syntax  and  semantics  of  the  capabilities  are  defined  by 
the  Server  in  the  PICS.  Any  deviation  from  the  defined 
syntax  and  semantics  is  grounds  for  the  Server  to  return  a 
service  error  with  Error  Class  = RESOURCE  and  Error  Code  = 
CAPABILITY-UNKNOWN . 


20 ■ 5 ■ 6 . 3Download  Segment  Service 

If  a negative  response  to  a Download  Segment  request  is 
received,  an  MMS  server  will  not  send  any  more  Download 
Segment  requests,  but  will  next  send  either  a Terminate 
Download  Sequence  request  or  an  Abort  request.  A client  who 
receives  another  Do’ivmload  Segment  Indication  should  issue 
either  a service  error,  specifying  an  Error  Class  = SERVICE 
and  an  Error  Code  = PRIMITIVES -OUT-OF- SEQUENCE,  or  an  Abort 
request . 


20 . 5 . 6 ■ 4Terminate  Download  Sequence  Service 

If  a Server  has  not  received  a response  to  a Download 
Segment  request  with  a value  of  the  More  Follows  parameter  = 
FAISE,  it  will  not  issue  a Terminate  Download  Sequence 
service  request  unless  that  request  specifies  a Discard 
parameter  value  of  TRUE.  If  a Client  receives  a Terminate 
Download  Sequence  request  in  which  the  Discard  parameter  is 
either  absent  or  has  a value  FALSE,  and  it  has  not 
previously  issued  a parameter  value  of  More  Follows  = FALSE 
in  response  to  a Download  Segment  request,  it  shall  behave 
exactly  as  if  it  had  received  a Terminate  Download  Sequence 
service  request  with  the  Discard  parameter  = TRUE. 
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20 ■ 5 . 6 ■ SInitiate  Upload  Sequence  Service 


The  List  of  Capability  parameter  will  follow  the  limitations 
of  20.5.6.1. 


20 . 5 . 6 . SUpload  Segment  Service 

If  a Client  receives  a negative  confirm  to  an  Upload  Segment 
request,  it  will  not  send  any  more  Upload  Segment  requests. 
The  next  service  primitive  sent  will  be  either  a Terminate 
Upload  Sequence  request  or  an  Abort  request.  A Server  who 
receives  another  Upload  Segment  indication  should  issue 
either  a service  error,  specifying  an  Error  Class  = SERVICE 
and  an  Error  Code  = PRIMITIVES -OUT-OF- SEQUENCE , or  an  Abort 
request . 


20.5.6.7Get  Domain  Attributes  Service 


The  List  of  Capability  parameter  will  follow  the  limitations 
of  20.5.6.1. 


20.5.7Get  Capability  List  Service 

The  List  of  Capability  parameter  will  follow  the  limitations  of 
20.5.6.1. 

20,6  INTEROPERABILITY  AGREEMENTS 


These  implementation  agreements  will  allow  IS  based 
implementations  to  interoperate  with  DIS  based  implementations  as 
described  in  Appendix  A.  To  achieve  this  interoperability,  the  IS 
implementation  shall  support  all  of  the  agreements  in  this 
section. 


TUTORIAL  SECTION: 

There  are  three  types  of  implementations  when  considering  MMS 
interoperabilty . 

IMP-1 :An  implementation  based  on  DIS  9506  as  described  in 
Appendix  A. 

IMP-2: An  implementation  based  on  IS  9506  with  no 
interoperability  agreements  applied. 
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IMP- 3: An  implementation  based  on  IS  9506  which  includes  the 
interoperabilty  agreements  described  below. 

IMP-1,  IMP-2,  and  IMP-3  can  interoperate  with  each  other  in  all 
combinations  with  the  exception  of  the  IMP-1  and  IMP-2 
combination.  The  remainder  of  this  section  describes  additional 
agreements  which  change  an  IMP-2  implementation  into  an  IMP- 3 
implementation. 


20 . 6 . iCalling  MMS-user  Interoperability  Asreements 

A calling  MMS-user  shall  be  capable  of  receiving  and  supporting 
a negotiatedVersionNumber  parameter  in  the  Initiate  Service 
Confirm  of  zero. 

A calling  MMS-user  which  has  received  a negotiatedVersionNumber 
parameter  in  the  Initiate  Service  Confirm  of  zero  shall  support 
the  modifications  described  in  section  20.6.3. 

A calling  MMS-user  shall  ignore  the  Application  Context  Name 
parameter  in  the  A-Associate  Confirm. 

A calling  MMS-user  which  has  received  a 
negotiatedVersionNumber  of  zero  shall  be  capable  of 
receiving  and  supporting  an  InitiateResponse  which  has 
been  encoded  according  to  the  modifications  described  in 
Appendix  A,  specifically  the  capability  of  receiving  and 
supporting  a negotiatedParameterCBB  containing  exactly  7 
bits . 


20.6.2Called  MMS-user  Interoperability  Agreements. 

A called  MMS-user  shall  be  capable  of  receiving  and  supporting 
a proposedVersionNumber  parameter  in  the  Initiate  Service 
Indication  of  zero. 

A called  MMS-user  which  has  received  a proposedVersionNumber 
parameter  in  the  Initiate  Service  Indication  of  0 shall  support 
the  modifications  in  section  20.6.3. 

A called  MMS-user  shall  ignore  the  Application  Context  Name 
parameter  in  the  A-Associate  Indication. 

A called  MMS-user  shall  be  capable  of  receiving  and  supporting 
an  InitiateRequest  chich  has  been  encoded  according  to  the 
modifications  described  in  Appendix  A,  specifically  the 
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capability  of  receiving  and  supporting  a proposedParameterCBB 
containing  exactly  7 bits. 


20 . 6 . 3General  Interoperability  Agreements 


20.6.3. IVMD  Logical  Status 

If  the  current  VMD  State  is  SUPPORT- SERVICES -ALLOWED  and  the 
association  minor  version  number  is  zero,  then  the 
vmdLogicalStatus  parameter  shall  have  a value  of  state- 
changes-  allowed  in  a status  response  or  a unsolicitedStatus 
request . 

20.6.3.2 

Further  agreements  are  required  to  complete  this  section. 
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20.7  APPENDIX  A:DIS  9506  MODIFICATIONS  REQUIRED  FOR 

INTEROPERABILITY 


This  appendix  is  an  integral  part  of  chapter  20.  It  documents  the 
modifications  to  DIS  9506  required  to  describe  implementations  for 
which  the  IS  agreements  provide  interoperability.  This  appendix 
as  applied  to  DIS  9506  is  referred  to  as  Version  0. 


20.7. IReferences 

[1]  MMS/lManufacturing  Message  Specification  - ISO  DIS  9506  - 
Service  Definition,  December  1987 

[2]  MMS/2Manufacturing  Message  Specification  -ISO  DIS  9506  - 
Protocol  Specification,  December  1987 

[3]  NBS  OSI  Implementors  Workshop  Agreements  - December  1987 


20 . 7 . 2Version  0 


20.7.2. IGeneral 


20 . 7 . 2 . 1 . limplementation  Base 

Version  0 is  based  upon  Reference  [3]  in  20.7.2  as  it 
applies  to  MMS , 


20 . 7 . 2 . 1 . 2Rules  of  Extensibility 

The  following  sentence  is  appended  to  the  last  paragraph  in 
section  8. 2. 1.1. 5. 2 Proposed  Parameter  CBB  and  the  last  paragraph  in 
section  8. 2. 1,2. 5. 2 Negotiated  Parameter  CBB  of  DIS  9506-1. 

"Any  additional  bits  shall  be  ignored," 


20 . 7 . 2 . 2Modif ications  to  the  Protocol  definitions 


20.7.2.2. lPage39.  Section  7.5.2  of  DIS  9506-2 
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CHANGE 

reportEventEnrollmentStatus  [60]  IMPLICIT 
ReportEventEnrollmentStatus -Request , 

TO 

reportEventEnrollmentStatus  [60] 

ReportEventEnrollmentStatus -Request , 


20.7.2.2.2Page  49,  Section  7.6.4.  PIS  9506-2 

CHANGE 

ApplicationReference  ; :=  SEQUENCE  { 

ap-titleISO-8650-ACSE-l .AP-title  OPTIONAL, 

ap- invocation- idISO-86  50-ACSE-l .AP- invocation- id  OPTIONAL, 
ae-qualifierISO-8650-ACSE-l .AE-qualifier  OPTIONAL, 
ae- invocation- idISO-8650-ACSE- 1 ,AE- invocation- id  OPTIONAL 
} 

TO 

ApplicationReference  : :=  SEQUENCE  { 

ap-title  [0]  OBJECT  IDENTIFIER  OPTIONAL, 
ap- invocation- id  [1]  INTEGER  OPTIONAL, 
ae-qualifier[2]  INTEGER  OPTIONAL, 
ae-invocation-id[3]  INTEGER  OPTIONAL 
} 


20.7.2.2.3Page  95.  Section  12.2.1  of  PIS  9506-2 

CHANGE 

structure  [2]  IMPLICIT  SEQUENCE  OF  SEQUENCE  { 
TO 

structure  [2]  IMPLICIT  SEQUENCE  { 

20.7.2.2.4Page  96.  Section  12.3.1  of  PIS  9506-2 
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CHANGE 

named  [4]  IMPLICIT  SEQUENCE  { 

TO 

named  [5]  IMPLICIT  SEQUENCE  { 

20.7.2.2.5Page  98.  Section  12.4.2  of  PIS  9506-2 

CHANGE 

generalized- time  [10]  IMPLICIT  GeneralizedTime , 

TO 

generalized- time  [11]  IMPLICIT  GeneralizedTime, 

20.7.2.2.6Page  138.  Section  15.14  of  PIS  9506-2 

CHANGE 

additionalDetail  [9]  IMPLICIT  EE-Additional-Detail 

OPTIONAL 

TO 

additionalDetail  [9]  EE-Additional-Detail  OPTIONAL 

20.7. 2.2. 7Page  166.  Section  17.10  of  PIS  9506-2 

CHANGE  the  transfer  syntax  object  identifier  value  from 
{ iso  asnl(l)  basic-encoding(l)  ) 

TO 

{ j oint- iso-ccitt  asnl(l)  basic-encoding(l)  ) 


20 ■ 7 . 2 ■ 3Behavioral  Requirements 
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20.7.2.3. 1 Filenames 


File  Names  are  specified  in  accordance  with  the  NBS 
Implementors ' agreements  for  FTAM  Reference  [3]  in  20,7.2. 


20 . 7 . 2 . 3 . 2Identifv  Service 

In  the  Identify  service,  the  vendor,  model  and  revision 
fields  may  be  of  any  length,  but  only  the  first  64,  16,  and  16  octets 
respectively  are  treated  as  significant. 


20 . 7 . 2 . 3 . 3Initiate  Service 


An  MMS  Client  will: 

1. propose  1 or  greater  for  the  value  of  the  Proposed  Max  Serv 
Outstanding  Called  parameter  in  the  Initiate  service  when  initiating 
the  application  association  (calling) . 

2. offer  1 or  greater  for  the  value  of  the  Negotiated  Max  Serv 
Outstanding  Calling  parameter  in  the  Initiate  service  when  receiving 
the  application  association  initiation  (called) . 

An  MMS  Server  will: 

1. propose  1 or  greater  for  the  value  of  the  Proposed  Max  Serv 
Outstanding  Calling  parameter  in  the  Initiate  service  when  initiating 
the  application  association  (calling) . 

2. offer  1 or  greater  for  the  value  of  the  Negotiated  Max  Serv 
Outstanding  Called  parameter  in  the  Initiate  service  when  receiving 
the  application  association  initiation  (called) . 


20 . 7 . 2 . 3 . 3 . iSegment  Size 


20.7.2.3.3.1.1  Minimum  Segment  Size 

MMS  implementations  are  able  to  parse  and  process  512  octets 
of  MMSpdu  as  they  are  encoded  in  ASN.l  basic  encoding  rules. 


20.7.2.3.3.1.2  Maximum  Sesment  Size 
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The  Max  Segment  Size  is  defined  as  the  maximum  number  of 
octets  in  an  MMS  pdu  encoded  using  the  negotiated  transfer  syntax. 
This  size  will  apply  to  all  MMS  pdus  with  the  exception  of  the 
initiate-Request  PDU,  Initiate-Response  PDU,  and  the  initiate -Error 
PDU.  The  max  segment  size  will  be  negotiated  during  connection 
initiation  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max 
Segment  Size  parameters  of  the  MMS  initiate  service. 

The  Max  Segment  Size  will  be  applied  as  follows: 

Any  received  MMSpdu  which  is  less  than  or  equal  to  the  Max 
Segment  Size  will  be  properly  parsed  and  processed. 

An  MMS  implementation  will  not  send  an  MMSpdu  whose  size 
exceeds  the  Max  Segment  Size. 


20 . 7 . 2 . 3 . 3 . 2Abstract  Syntax  Name 


The  ASN.l  object  identifier  value  for  the  abstract  syntax 
name  will  be  the  same  as  specified  on  page  166,  section  17.10  DIS 
9506-2. 


20,7.2.3.3.3  Application  Context  Name 

The  ASN.l  object  identifier  value  for  the  application  context 
name  will  be  the  same  as  specified  on  page  166,  section  17.11  DIS 
9506-2. 


An  MMS-user  ignores  the  Application  Context  Name  in  the  A- 
Associate  indication  and  the  A-Associate  confirm. 


20.7.2.3. 4Minor  Vers  ion  Number 


The  Minor  Version  Number  is  zero. 


20 ■ 7 . 2 ■ 3 . SParameter  CBB  Subset 

The  following  subset  of  MMS  Parameter  CBBs  were  considered 
during  preparation  of  this  appendix. 

STRl, 

NEST, 

VADR, 

VW!! 
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20 . 7 ■ 3Service  Subset 


The  following  subset  of  MMS  services  were  considered  during 
preparation  of  this  appendix. 

Initiate , 

Conclude , 

Cancel , 

Status , 

GetNameList , 

Identify, 

UnsoiicitedStatus , 

GetCapabilityList , 

InitiateDownloadSequence , 

DownloadSegment , 

TerminateDownloadSequence , 

InitiateUploadSequence , 

UploadSegment , 

TerminateUploadSequence , 

RequestDomainDownload, 

Reques  tDomainUp load , 

LoadDomainContent , 

StoreDomainContent , 

DeleteDomain, 

GetDomainAttributes , 

Read, 

Write , 

Inf ormationReport , 

GetVariableAccessAttributes , 

Input , 

Output , 

TakeControl , 

RelinquishControl , 

ReportSemaphoreStatus , 

ReportPooiSemaphoreStatus , 

ReportSemaphoreEntryStafJs , 

CreateProgramInvocat ion , 

DeleteProgramInvocation, 

Start , 

Stop , 

Resume , 

Reset , 

Kill, 

GetProgramInvocatiorsAttributes , 

ObtainFile , 

GetEventConditionAttributes , 

ReportEventConditionStatus , 
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GetAlarmSummary , 
ReadJournal , 
WrlteJournal , 
InitializeJournal , 
CreateJournal , 

De le te J ournai , 
ReportJournalStatus 
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This  International  Standardized  Profile  is  defined  within  the  context  of  Functional  Standardization,  in 
accordance  with  the  principles  specified  by  ISO  TR  10000,  Taxonomy  Framework  and  Directory  of 
Profiles."  The  context  of  Functional  Standardization  Is  one  part  of  the  overall  field  of  Information 
Technology  (IT)  standardization  activities,  covering  base  standards,  profiles,  and  registration  mechanisms. 
A profile  defines  a combination  of  base  standards  that  collectively  perform  a specific  well-defined  IT 
function.  Profiles  standardize  the  use  of  options  and  other  variations  in  the  base  standards,  and  provide  a 
basis  for  the  development  of  uniform,  internationally  recognized  system  tests. 

This  International  Standardized  Profile  was  developed  in  close  cooperation  between  the  three 
International  OSI  Workshops;  the  NIST  OSI  Implementors  Workshop  (NIST  OIW),  the  European  Workshop 
for  Open  Systems  (EWOS),  and  the  AsiaOceania  Workshop  (AOW).  The  text  is  harmonized  between 
these  three  Workshops  and  was  ratified  by  the  Workshops’  plenary  assemblies. 

This  International  Standardized  Profile  contains  an  informative  Annex  A - Character  Set  Technology. 

21.1.  Scope 

This  International  Standardized  Profile  desaibes  Information  Processing  Character  Set  agreements 
covering  character  set  usage  in  referencing  Application  Service  Elements  and  OSI  Applications.  These 
agreements  are  based  upon  ISO  Character  Set  International  Standards  and  CCITT  Character  Set 
Recommendations.  The  informative  Annex  A summarizes  the  character  set  practices  within  referencing 
Application  Service  Elements  and  OSI  Applications  including  all  relevant  encoding  information  drawn  from 
the  appropriate  ISO  Registers,  ISO  Standards,  and  CCITT  Recommendations. 

21.1.1.  Recording  Additional  Character  Sets 

This  International  Standardized  Profile  does  not  prevent  Application  Service  Elements  from  adding  new 
graphic  character  sets  or  control  function  sets.  When  new  character  sets  are  to  be  added,  however,  they 
shall  be  recorded  in  this  International  Standardized  Profile. 

21.1.2.  General  Applicability  of  Character  Sets 

For  the  purpose  of  this  International  Standardized  Profile  when  new  character  sets  are  to  be  added, 
efforts  shall  be  made  to  obtain  agreement  on  their  uses  among  Application  Service  Elements  so  that  they 
are  generally  applicable. 

21.1.3.  Minimum  Number  of  Character  Sets 

The  number  of  character  sets  supported  will  be  kept  to  the  minimum  possible  so  as  to  maximize 
interoperability. 


21.2.  References 
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The  following  Internationa!  Standards  and  CCITT  Recommendations  are  referenced  in  this  International 
Standardized  Profile: 

[CCITT-T.61-1984,  1985  #22] 

[DIS8859-7-1987,  1987  #30;  ISO2022-1986.  1986  #1;  1306429-1983,  1983  #9;  IS0646-1983,  1983 
#10;  IS06937/M983,  1983  #29;  IS06937/2-1 983,  1983  #8;  IS08824-1987,  1987  #26;  IS08825- 
1937,  1987  #27;  1308859-1:1987,  1987  #6;  ISOREG,  1989  #2] 

21.3.  Definitions 

21.3.1.  character  data: 

Character  data  is  defined  to  be  graphic  characters  and  control  functions  as  defined  by  ISO  2022  and  the 
appropriate  Internationa!  Standards. 

21.3.2.  composite  graphic  symbol: 

A composite  graphic  symbol  is  defined  for  the  purposes  of  this  international  Standardized  Profile  as  a non- 
spacing diacritical  in  combination  with  an  alphabetic  as  in  ISO  6937. 

21.4.  Abbreviations 

21.4.1.  ASN.1: 

ASN.1  is  an  abbreviation  for  Abstract  Symbolic  Notation  One. 

21.4.2.  IRV 

IRV  is  an  abbreviation  for  International  Reference  Version. 

21.5.  Position  within  the  Taxonomy 

«The  formal  position  of  this  International  Standardized  Profile  within  the  taxonomy  is  currently 
unknown. » 

It  may  be  referenced  from  the  ISP  for  any  application  service  element  or  031  application. 

21.6.  Conformance 

Implementations  claiming  conformance  to  this  ISP  must  designate  one  or  more  of  the  Character  Set 
Profiles  defined  herein. 

Imaging  of  Graphic  Characters  is  not  required  by  this  ISP.  Imaging  conformance  may  be  defined  in  the 
specific  Upper  Layers  Requirements  section  of  the  referencing  ISP.  If  no  imaging  requirements  are 
specified,  then  there  are  no  conformance  requirements. 

21.6.1.  Processed  Character  Data 

Processed  character  data  is  character  data  which  must  be  processed  by  the  Application  Service  Element 
or  OSI  Application,  for  example,  store  and  forward  character  data. 

Senders  of  character  data  must  not  produce  invalid  character  codes  or  invalid  designating  or  invoking 
escape  sequences. 

21.6.1.1.  Non-supported  Character  Sets 
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If  an  implementation  receives  a designating  escape  sequence  for  a character  set  that  it  is  not  able  to 
interpret,  then  it  shall  regard  that  sequence  as  "invalid  data."  If  possible,  it  will  signal  this  error  in  a way  that 
is  appropriate  to  the  protocol  definition.  For  applications  for  which  there  is  no  protocol,  then  no  error  need 
be  returned.  It  will  not  be  required  to  interpret  any  following  characters  that  are  within  that  data  item. 

21.6.1.2.  Reserved  Character  Codes 

If  an  implementation  receives  a coded  character  that  is  specified  in  the  standard  to  be  "reserved  for  future 
standardization,"  it  shall  not  be  considered  an  error.  An  imaging  device  shall  indicate  receipt  of  such  a 
reserved  character  to  the  user  in  am  implementation  defined  way,  e.g.  by  making  available  a character  that 
need  not  be  distinguishable  from  one  of  the  other  characters  specified  in  the  standard. 

If  receivers  reject  or  discard  invalid  character  codes,  an  appropriate  error  code  must  be  returned. 

21.6.1.3.  Validation  of  Character  Codes 

Character  codes  within  the  scope  of  a standard  for  which  there  is  no  definition  in  the  code  table  are 
defined  to  be  invalid  character  codes.  An  invalid  escape  sequence  is  any  designating  or  invoking  escape 
sequence  which  is  not  defined  in  these  agreements. 

Implementations  must  conform  to  the  following  statement. 

• Originators  of  data  shall  not  produce  invalid  character  codes  or  invalid  designating  or  Invoking  escape 
sequences. 

21.6.2.  Unprocessed  Character  Data 

Unprocessed  character  data  is  character  data  which  is  not  processed  by  the  Application  Service  Element 
or  OS  I Application,  for  example,  character  matching. 

21.6.2.1.  Validation  of  Character  Codes 

Character  codes  within  the  scope  of  a standard  for  which  there  is  no  definition  are  defined  to  be  invalid 
character  codes.  An  invalid  escape  sequence  is  any  designating  or  invoking  escape  sequence  which  is 
not  defined  in  these  agreements. 

Implementations  must  conform  to  the  following  statements. 

• Receivers  need  not  validate  character  codes  or  designating  or  invoking  escape  sequences. 

• Senders  who  do  not  originate  data  need  not  validate  character  codes. 

21.7.  Genera!  Agreements 

The  agreements  recorded  in  this  section  cover  all  character  set  usage  except  where  explicitly  noted  to  the 
contrary.  Additional  agreements  specific  to  individual  character  sets  are  recorded  In  the  individual 
character  set  profiles. 

21.7.1.  Encoding 

The  following  agreements  cover  various  aspects  of  character  encoding. 

21.7.1.1.  Overprint,  Composite  Characters 

A composite  graphic  symbol  is  considered  as  one  character  for  purposes  of  comparison  and  character 
string  length  computation. 

With  the  exception  of  composite  graphic  symbols,  sequences  of  graphic  characters  and  control  functions 
which  would  result  in  the  presentation  of  two  or  more  graphic  characters  in  a single  character  position  shall 
not  be  used.  So  for  example,  the  sequence  "a  BACKSPACE  ""  must  be  processed  as  three  characters 
rather  than  as  the  single  character  S. 
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21.7.1.2.  Code  Extension  FaclElties  for  GeneraEString  and  GraphicString 

This  section  constitutes  the  prior  agreement  on  code  extension  required  by  ISO  2022. 

For  ASN,1  Generalstring  and  Graphicstring  types,  the  assumed  extension  facilities  are  as  though  the 
following  escape  sequences  from  iSO  2022  have  been  applied:  ESC  2/0  4/3,  ESC  2/0  4/9,  and  ESC  2/0 
5/10.  These  sequences  indicate: 

• 8-btt  environment; 

• the  GO,  and  G1  graphic  sets  shall  be  used; 

• the  designating  escape  sequences  also  invoke  the  GO  and  G1  sets  into  columns  02  to  07  and  10  to 
15  respectively; 

• no  locking  shift  functions  shall  be  used; 

• the  graphic  character  sets  may  comprise  94  and/or  96  characters, 

• a G2  set  shall  be  used;  and, 

• characters  from  G2  may  be  accessed  by  use  of  the  single-shift  2 control  function. 

Designating  ESCAPE  sequences  in  a data  stream  are  permitted.  No  Announcers  of  extension  facilities 
may  be  used  within  these  ASN.1  string  types. 

21.7.1.3.  Initial  Conditions  for  TeSetexStrIng 

For  TeletexString  (T61  String)  the  initial  condition  is  described  in  CCITT  T.61  Annex  A,  Clause  A.2. 

21.7.2.  Comparisons 

This  section  contains  agreements  concerning  comparison  of  characters  during  processing. 

21.7.2.1.  f\/latch(ng  Characters 

A character  submitted  for  matching  with  another  character  does  not  have  to  be  drawm  from  the  same 
coded  character  set.  However,  the  match  is  restricted  to  characters  taken  from  arjy  pair  of  coded  character 
sets  for  which  equality  or  inequality  is  defined.  The  identifications  of  such  pairs  of  coded  character  sets 
are  shown  in  the  following  list.  The  result  of  comparing  characters  from  a pair  of  different  coded  character 
sets  not  in  this  list  is  undefined. 

(ISO  646,  ISO  6937-2) 

(ISO  646,  ISO  8859-1) 

(ISO  6937-2,  ISO  8859-1) 

Character  matching  is  defined  for  characters,  not  their  coded  representations.  The  character  must  take 
into  account  any  code  extension  techniques.  For  example,  the  character  named  "SMALL  LETTER  a 
WITH  DIAERESIS”  of  ISO  885S  must  match  the  character  named  "small  a with  diaeresis  or  umlaut  mark"  of 
ISO  6937  even  though  the  former  character  is  encoded  in  a single  octet  and  the  latter  in  two  octets. 

Two  characters  are  said  to  be  equal  if,  and  only  If,  their  names  are  identical.  The  names  are  recorded  in  the 
registration  of  the  character  sets  in  the  international  Register  of  Coded  Character  Sets  to  be 
used  with  Escape  Sequences  and  not  the  character  set  International  Standard  or  Recommendation. 

In  the  case  of  ISO  6937-2  the  names  of  the  composite  graphic  symbols  are  specified  in  the  standard  Itself. 
However  in  the  present  edition  there  are  some  systematic  differences  between  the  naming  conventions 
used  in  the  standard  and  those  used  in  the  ISO  Character  Set  Register  as  shown  below: 

ISO  6937  name:  capita!  A with  acute 

Qccsnt 

ISO  Ftegister  Name:  CAPITAL  LETTER  A 
WITH  ACUTE 
ACCENT 
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In  this  case,  two  characters  are  equal  if,  and  only  5f,  their  names  differ  only  by  the  inclusion  of  the  word 
LETTER  in  the  ISO  Register  Name.  For  those  characters  whose  names  do  not  follow  this  convention,  the 
following  list  defines  the  match: 

ISO  6937  Name  ISO  Register  Name 

«Editor's  Note:  to  be  filled  in> 

If  a character  set  registration  does  not  provide  character  names  then  matching  will  be  defined  by  exact 
matching  on  an  octet  by  octet  basis. 

«Editor's  Note:  The  problem  of  matching  Oriental  language  character  sets  is  for  further  study. » 

In  comparing  strings  all  control  functions  except  code  designation  and  invocation  extension  facilities  shall 
be  ignored.  SPACE  is  treated  as  a graphic  character  in  such  comparisons. 

In  comparing  strings  when  a character  code  is  encountered  for  which  no  other  match  is  defined,  matching 
will  be  defined  by  exact  matching  on  an  octet  by  octet  basis. 

21.7.2.2.  Caseignore  Comparisons 

In  character  comparisons  in  which  case  is  ignored,  the  matching  rules  of  clause  21 .7.2.1  are  relaxed  in  that 
the  characters  are  equal  if  their  names  as  defined  in  clause  21.7.2.1  differ  only  by  one  name  having 
SMALL  where  the  other  name  has  CAPITAL. 

21.7.2.3.  Ordering  and  Comparing  Characters 

An  agreement  on  comparison,  other  than  equality  or  inequality,  between  characters  requires  a definition 
of  a collating  sequence.  This  document  contains  no  such  agreements. 

The  collating  sequence  of  letters,  accented  letters  and  other  graphic  symbols  is  not  currently  defined  in 
any  International  Standard  or  Recommendation. 

Preferred  collating  sequences  might  vary  between  countries. 

21.7.2.4.  Comparing  Encoded  ASN.1  Character  Strings 

In  this  section  a character  string  is  considered  to  be  a sequence  of  characters  some  of  which  may  be 
composed  of  multiple  bytes  depending  upon  the  character  set  encodings  v^hich  are  specified. 
Comparing  two  character  strings  gives  the  same  result  independent  of  each  character  string's  encoding, 
for  example,  the  comparison  is  independent  of  the  Basic  Encoding  Rules  for  ASN.l : 

• as  constructed  or  primitive  form,  or, 

• as  definite  or  indefinite  length  form. 

21.8.  Character  Set  Profiles 

A Character  Set  Profile  summarizes  implementation  agreements  specific  to  a particular  character  set. 
Character  Set  Profiles  are  identified  in  the  following  manner: 

CSn-m 

where: 

CS  means  CLaracier  Set 

n = 1 designates  a profile  for  a graphic  character  set 

n = 2 designates  a profile  for  a control  function  set 

m is  a number  uniquely  identifying  the  Character  Set  Profile. 
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The  values  of  n and  m are  defined  in  this  agreement.  Names  of  Character  Set  Profiles  are  also  defined  in 
this  International  Standardized  Profile. 

This  section  covers  agreements  about  Character  Set  Standards  and  Recommendations  including: 

• subrepertoires  supported, 

• standardized  options  selected, 

• component  character  sets  and  their  registrations  in  the  International  Register  of  Coded 
Character  Sets  to  be  used  with  Escape  Sequences  where  there  is  a choice  to  be  made,  or 
the  standard  does  not  specify  it,  and, 

• the  designation  of  component  character  sets  within  the  ISO  2022  Code  Extension  Model  where  there 
is  a choice  to  be  made. 

The  General  Agreements  of  the  preceding  section  apply  to  each  of  these  Character  Set  Profiles. 

21.8.1.  CS1-1  ISO  646  Graphic  Character  Set 

21.8.1.1.  Base  Standard 

Internationa!  Standard  646  - 1983,  Information  Processing  — ISO  7-bit  coded  character  set  for  information 
interchange. 

« Editor's  Note:  These  agreements  wiil  be  based  on  the  new  DIS  646. » 

21.8.1.2.  Subrepertoire  or  Version 

International  Reference  Version 

21.8.1.3.  Standard  Options  Selected 

Composite  graphic  symbols  are  covered  by  General  Agreements. 

21.8.1.4.  Character  Set  Components  and  Designated  Position 

IRV  of  ISO  646  number  2 in  GO 

«Editor's  Note:  This  will  change  to  number  6.» 

Space  is  in  2/0 

21.8.1.5.  Other  Agreements 

None. 

21.8.2.  CS1-2  JIS  X0208 

«Editor's  Note:  to  be  defined. » 

21.8.3.  CS1"3  CCITT  Recommendation  T.61  Graphic  Character  Sets  Basic  Teletex 
Profiles 

21.8.3.1.  Base  Standard 

CCITT  Recommendation  T.61  - 1985,  Character  Repertoire  and  Coded  Character  Sets  for  the 
International  Teletex  Service. 

«Editor's  Note:  These  references  will  be  updated  as  soon  as  the  1989  versions  are  published.» 

21.8.3.2.  Subrepertoire  or  Version 


21-6 


Character  Set  Agreements 


March  1990  (Working) 


None 

21.8.3.3.  Standard  Options  Selected 

None 

21.8.3.4.  Character  Set  Components  and  Designated  Position 

Teletex  Primary  Graphic  Set  102  in  GO 
Teletex  Supplementary  Graphic  Set  103  in  G2 
SPACE  in  2/0 

21.8.3.5.  Other  Agreements 

Support  for  CCITT  Recommendation  T.61  as  an  ASN.1  GeneralString  is  outside  of  this  International 
Standardized  Profile. 

Support  of  the  graphic  set  components  of  T.61  as  an  ASN.1  Graphicstring  is  outside  the  scope  of  this 
International  Standardized  Profile. 

Use  of  CCITT  Recommendation  T.61  except  where  mandated  by  standards  is  outside  the  scope  of  this 
International  Standardized  Profile.  Exceptions  to  this  rule  for  specific  Application  Service  Element 
protocol  elements  must  be  documented  by  the  referencing  Application  Service  Elements  or  OSI 
Applications. 

21.8.4.  CS1-4  ISO  8859-1  Latin  Alphabet  No.  1 

21.3.4.1.  Base  Standard 

International  Standard  8859-1  - 1987,  Information  processing  — 8-bit  single-byte  coded  graphic  character 
sets  — Part  1:  Latin  alphabet  No.  1. 

21.8.4.2.  Subrepertoire  or  Version 
Not  applicable. 

21.8.4.3.  Standard  Options  Selected 

Not  applicable. 

21.8.4.4.  Character  Set  Components  and  Designated  Position 

ASCII  Graphic  Character  Set  number  6 in  GO 

Right  hand  part  of  Latin  Alphabet  No.  1 number  100  in  G1 

21.8.4.5.  Other  Agreements 

None. 

21.8.5.  CS1-5  ISO  6937-2  Coded  Character  Sets  for  Text  Communication 
21.8.5.1.  Base  Standard 

International  Standard  6937/2  - 1983,  Information  Processing  — Coded  character  sets  for  text 
communication  — Part  2:  Latin  alphabetic  and  non-alphabetic  graphic  characters. 
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«Editor's  Note:  Includes  Addendum  1 as  soon  as  it  is  published.» 

21.8.5.2.  Subrepertoire  or  Version 

Full  number  0 
Minimum  number  1 
Teletex  number  3 

Western  European  Data  Processing  number  9 

21.8.5.3.  Standard  Options  Selected 

Not  applicable 

21.8.5.4.  Character  Set  Components  and  Designated  Position 

IRV  of  ISO  646  number  2 in  GO 

« Editor's  Note:  This  will  change  to  number  6.» 

Supplementary  set  of  Latin  Text  Processing  number  142  in  G2 

21.8.5.5.  Other  Agreements 

For  subrepertoires  2 and  5,  the  supplementary  set  may  be  omitted  at  the  discretion  of  the  sending 
application. 

21.8.6.  CS1-6  ISO  8859/7  Greek  Supplementary  Set 

«Editor's  Note:  to  be  defined. » 

21.8.7.  CS1-7  CCITT  Recommendation  T.61  Graphic  Character  Sets  Basic  Teletex 
Profiles  (1984) 

21.8.7.1.  Base  Standard 

CCITT  Recommendation  T.61  - 1981 , Character  Repertoire  and  Coded  Character  Sets  for  the 
International  Teletex  Service. 

21.8.7.2.  Subrepertoire  or  Version 

None 

21.8.7.3.  Standard  Options  Selected 

None 

21.8.7.4.  Character  Set  Components  and  Designated  Position 

Teletex  Primary  Graphic  Set  102  in  GO 
Teletex  Supplementary  Graphic  Set  103  in  G2 
SPACE  in  2/0 

21.8.7.5.  Other  Agreements 
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Support  for  CCITT  Recommendation  T.61  as  an  ASN.1  GeneralString  is  outside  of  this  International 
Standardized  Profile. 

Support  of  the  graphic  set  components  of  T.61  as  an  ASN.1  Graphicstring  is  outside  the  scope  of  this 
International  Standardized  Profile. 

Use  of  CCITT  Recommendation  T.61  except  where  mandated  by  standards  is  outside  the  scope  of  this 
International  Standardized  Profile.  Exceptions  to  this  rule  for  specific  Application  Service  Element 
protocol  elements  must  be  documented  in  the  referencing  Application  Service  Elements  or  OSI 
Applications. 

This  profile  is  intended  for  use  with  the  X.400-1984  implementation  agreements  only. 

21.8.8.  CS  1-8  CCITT  Recommendation  T.61  Graphic  Character  Sets 

«Editor's  Note:  to  be  defined.» 

21.8.9.  Korean  National  Character  Set 

«Editor's  Note:  to  be  defined. » 

21.8.10.  CS2-1  ISO  646  CO  Control  Functions 

21.8.10.1.  Base  Standard 

International  Standard  646  - 1 983,  Information  Processing  — ISO  7-bit  coded  character  set  for  information 
interchange. 

21.8.10.2.  Subrepertoire  or  Version 
None. 

21.8.10.3.  Standard  Options  Selected 

None. 

21.8.10.4.  Character  Set  Components  and  Designated  Position 

ISO  646  CO  Set  number  1 in  CO 
DELETE  in  7/15 

21.8.10.5.  Other  Agreements 

When  a single  format  effector  for  vertical  (or  horizontal)  movement  is  optionally  permitted  to  effect  a 
combined  vertical  and  horizontal  movement,  implementations  shall  not  use  this  single  format  effector  for 
effecting  the  combined  vertical  and  horizontal  movement. 

21.8.11.  CS2-2  ISO  6429  Additional  Control  Functions 

21.8.11.1.  Base  Standard 

Internationa!  Standard  6429  - 1 983,  Information  Processing  — ISO  7-bit  and  8-bit  coded  character  sets  — 
Additional  control  functions  for  character-imaging  devices. 

21.8.11.2.  Subrepertoire  or  Version 
None. 

21.8.11.3.  Standard  Options  Selected 
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None. 

21.8.11.4.  Character  Set  Components  and  Designated  Position 

Cl  Control  Set  of  ISO  6429-1983  number  77  in  Cl 

21.8.11.5.  Other  Agreements 

None. 

21.8.12.  CS2-3  CCITT  Recommendation  T.61  Control  Sets 

21.8.12.1.  Base  Standard 

CCITT  Recommendation  T.61  - 1985,  Character  Repertoire  and  Coded  Character  Sets  for  the 
International  Teletex  Service. 

«Editor's  Note:  These  references  will  be  updated  as  soon  as  the  1989  versions  are  published.» 

21.8.12.2.  Subrepertoire  or  Version 

None. 

21.8.12.3.  Standard  Options  Selected 

Teletex  optional  repertoire  of  control  functions  is  not  selected. 

21.8.12.4.  Character  Set  Components  and  Designated  Position 

Teletex  Primary  Set  of  Control  Functions  number  106  in  CO 

Teletex  Supplementary  Set  of  Control  Functions  number  107  in  Cl 

21.8.12.5.  Other  Agreements 

None. 

21.8.13.  CS2-4  CCITT  Recommendation  T.61  Control  Sets  (1984) 

21.8.13.1.  Base  Standard 

CCITT  Recommendation  T.61  - 1981 , Character  Repertoire  and  Coded  Character  Sets  for  the 
international  Teletex  Service. 

21.8.13.2.  Subrepertoire  or  Version 
None. 

21.8.13.3.  Standard  Options  Selected 

Teletex  optional  repertoire  of  control  functions  is  not  selected. 

21.8.13.4.  Character  Set  Components  and  Designated  Position 

Teletex  Primary  Set  of  Control  Functions  number  106  in  CO 

Teletex  Supplementary  Set  of  Control  Functions  number  107  in  Cl 

21.8.13.5.  Other  Agreements 

This  profile  is  intended  for  use  with  the  X. 400-1 984  implementation  agreements  only. 
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Annex  A 

Character  Set  Technology 

(This  Annex  does  not  form  part  of  these  agreements.) 


A.1.  Introduction 

This  Annex  presents  information  from  information  Processing  Character  Set  Standards  which  is  relevant 
to  the  impiementation  of  OS!  Services.  The  intent  is  to  collect  into  one  place  the  most  relevant  information 
for  implementors  from  character  se?,  standards  specified  in  OS!  and  OS!  related  standards. 

A. 2.  Scope 

Material  in  this  Annex  is  drawn  from  !SO  and  CCITT  Character  Set  standards  and  Recommendations. 
Topics  covered  include  Character  Set  Extension  Techniques  and  Character  Set  Encodings.  ASN.1  Basic 
Encoding  Rules  are  reviev»fed  also.  Rationale  for  the  implementation  agreements  in  the  ISP  is  provided 
where  appropriate. 

A. 3.  Field  of  Appiicatloo 

This  annex  covers  character  set  information  for  ASN.1  Basic  Encoding  Rules  as  used  by  OSI  services.  It 
also  includes  information  pertaining  to  OS!  Interchange  Formats  such  as  Office  Document  Architecture. 

A.4.  Character  Set  Stanciards 

The  following  character  set  standards  have  some  relevance  to  this  material. 

[CCITT-T.  100- 1984,  1985  #23;  CCITT-T.50-1984,  1985  #20;  CClTT-T.51-1984,  1985  #21;  CCiTT-T.61- 
1 984,  1 985  #22j 

[ISO2022-1986,  1986  #1;  IS02375-1985,  1985  #7;  1S04873-1986,  1986  #4;  1S06429-1983,  1983  #9; 
1S0646-1983,  1983  #10;  IS06937/2-1983,  1983  #8;  1307350-1984,  1984  #5;  1S08824-1987,  1987 
#26;  IS08825-1987,  1987  #27;  1308859-1:1987,  1987  #6;  ISOREG,  1989  #2] 


A.5c  lotrodyctioo  to  Character  Set  Stanciards 

A brief  introduction  to  reading  a character  set  standard  is  presented  here  for  the  uninitiated.  Most  of  the 
character  set  standards  described  in  this  Annex  use  the  term  "bit  combinations"  to  refer  to  the  ordered 
string  of  bits  which  compose  a character.  Most  implementations  of  these  standards  allocate  an  8-bit  byte 
to  a character  and  consequentiy  tend  to  intermix  the  notions  of  bytes  and  characters.  In  the  OSI 
environment,  8-bit  bit  combinations  are  normally  referred  to  as  "octets." 

A ciiaracter  set  standard  generally  presents  its  character  encodings  in  a table  composed  of  1 6 rows  and  8 
or  16  columns  depending  on  whether  a 7-bit  or  an  8-bit  character  set  is  being  defined.  A given  ciiaracter 
code  is  generally  referenced  by  naming  its  column  and  then  its  row.  Thus  in  ISO  646  the  capita!  letter  A is 
referred  to  as  4/1 . Some  standards  precede  single  digits  with  a zero  so  that  in  ISO  8859/1  the  capital  letter 
A is  referred  to  as  04/01.  This  positional  notation  is  especially  important  in  the  consideration  of  the  code 
extension  techniques.  Code  extension  techniques  describe  characters  in  terms  of  their  position  only, 
without  regard  for  any  possible  previously  assigned  interpretations. 

A. 6.  Definitions 
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The  following  definitions  drawn  from  relevant  character  set  standards  are  provided  to  assist  in 
understanding  the  material  in  this  annex.  These  definitions  were  drawn  from  International  Standards 
which  were  current  at  the  time  of  drafting  this  document.  Any  conflict  between  these  definitions  and 
those  of  the  relevant  International  Standards  shall  be  resolved  by  using  the  definition  in  the  International 
Standard. 

bit  combination:  An  ordered  set  of  bits  that  represents  a character  or  is  used  as  a part  of  the 
representation  of  a character. 

byte:  A bit  string  that  is  operated  upon  as  a unit  and  the  size  of  which  is  independerst  of  redundancy  or 
framing  techniques. 

character:  A member  of  a set  of  elements  used  for  the  organization,  control  or  representation  of  data. 

code  extension:  The  techniques  for  the  encoding  of  characters  that  are  not  included  in  the  character  set 
of  a given  code. 

control  character:  A control  function  the  coded  representation  of  which  consists  of  a single  bit 
combination. 

control  function:  An  action  that  affects  the  recording,  processing,  transmission  or  interpretation  of  data 
and  that  has  a coded  representation  consisting  of  one  or  more  bit  combinations. 

graphic  character:  A character,  other  than  a control  function,  that  has  a visual  representation  normally 
handwritten,  printed  or  displayed. 

A.7.  ISO  2022  Information  Processing  — • ISO  7-bit  and  8-bit  coded 
character  sets  Code  extension  techniques 

This  International  Standard  was  originally  written  to  establish  extension  techniques  for  the  7-bit  codes  of 
ISO  646.  It  has  been  revised  twice  so  that  it  now  also  provides  the  basic  framework  for  an  8-bit  code  family 
which  is  compatible  with  the  7-bit  codes.  The  four  interrelated  clauses  cover 

• the  extension  of  the  7-bit  code  remaining  in  a 7-bit  environment; 

• the  structure  of  a family  of  8-bit  codes; 

• the  extension  of  an  8-bit  code  remaining  in  an  8-bit  environment; 

• the  relationship  between  the  7-bit  code  and  an  8-bit  code. 

The  middle  two  clauses  are  of  special  relevance  to  this  document  although  portions  of  the  others  should 
be  read  and  understood  in  order  to  set  the  context  for  the  relevant  material. 

Some  underlying  assumptions  from  the  standard  are  recorded  here  in  order  to  understand  the  context  of 
these  agreements.  Clause  2 notes  that  code  extension  techniques  are  designed  to  be  used  for  data  to 
be  processed  serially  in  a forward  direction. 

A. 7.1.  Structure  of  a FamSSy  of  8-b!t  codes 

Clause  7 of  the  standard  describes  a family  of  8-bit  codes  obtained  from  the  7-bit  set.  The  family  of  8-bit 
codes  is  obtained  by  the  addition  of  one  bit  to  each  of  the  bit  combinations  of  the  7-bit  code  producing  a 
set  of  256  8-bit  combinations.  The  characters  of  the  7-bit  code  are  assigned  to  the  128  bit  combinations 
for  which  the  eighth  bit  is  set  to  ZERO.  The  128  additional  bit  combinations  for  which  the  eighth  bit  is  set 
to  ONE  are  available  for  assignment.  The  8-bit  code  table  of  clause  7.1  is  a 16  by  16  array  of  columns 
numbered  00  to  15  and  rows  numbered  0 to  15.  Columns  08  and  09  are  provided  for  control  characters 
and  columns  1 0 to  1 5 for  graphic  characters. 

The  following  figure  shows  the  basic  code  structure  for  8-bit  character  codes.  This  structure  is  followed  by 
the  standards  described  in  this  annex. 
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8"bBt  Code  Strucfyre 


The  famiSy  concept  ss  described  in  clause  7.2  as 

a)  a set  of  32  additional  control  characters  can  be  selected  for  columns  08  and  09; 

b)  a set  of  94  or  96  additional  graphic  characters  can  be  selected  for  columns  1 0 to  1 5.  If  a set  of 
94  graphic  characters  is  invoked  in  columns  10  to  15,  positions  10/0  and  15/15  shall  not  be 
used. 

Three  control  functions  vi^ere  provided  by  ISO  646  for  purposes  of  code  extension.  ISO  2022  uses  these 
tfiree  and  adds  7 more  for  use  in  the  8-bit  environment.  For  reference  purposes  the  corresponding 
cfiaracters  from  the  7-bit  environment  are  shown  also.  The  following  table  shows  these  control  functions. 
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7-blt  Name 

Abbreviation 

8-bit  Name 

Abbreviation 

ESCAPE 

ESC 

ESCAPE 

ESC 

SHIFT-OUT 

SO 

LOCKING-SHIFT  ZERO 

LSO 

SHIFT- IN 

SI 

LOCKING-SHIFT  ONE 

LSI 

LOCKING-SHIFT  TWO 

LS2 

LOCKING-SHIFT  TWO 

LS2 

LOCKING-SHIFT  THREE 

LS3 

LOCKING-SHIFT  THREE 

LS3 

SINGLE-SHIFT  TWO 

SS2 

SINGLE-SHIFT  TWO 

SS2 

SINGLE-SHIFT  THREE 

SS3 

SINGLE-SHIFT  THREE 

SS3 

LOCKING-SHIFT  OfslE  RIGHT 

LSIR 

LOCKING-SHIFT  TWO  RIGHT 

LS2R  i 

LOCKING-SHIFT  THREE 
RIGHT 

LS3R  1 

A. 7.2.  Elements  of  Code  Extension  In  an  8-b!t  Environment 

The  elements  of  code  extension  in  an  8-bit  environment  are  shown  in  the  following  table  taken  from 
Clause  8.1  of  the  standard: 


Set 

Description 

Columns  occupied 

CO 

32  control  characters 

00  to  01 

Cl 

32  control  characters 

08  to  09 

GO 

94  graphic  characters 

02  to  07 

G1 

94  or  96  graphic  characters 

02  to  07  or  10  to  15 

G2 

94  or  96  graphic  characters 

02  to  07  or  1 0 to  1 5 

G3 

94  or  96  graphic  characters 

02  to  07  or  10  to  15 

A. 7. 3.  Multiple  Character  Sets 

«Describe  multi-level  designation  and  invocation  here.» 

The  standard  defines  a graphic  character  set  extension  strategy  in  which  a designating  escape  sequence 
is  used  to  select  up  to  four  graphic  character  sets  from  the  International  Character  Set  Register.  An 
invocation  sequence  is  then  used  to  select  up  to  two  graphic  sets  from  the  designated  sets  for  concise 
access  to  the  characters.  The  following  figure  shows  the  technique  for  the  8-bit  environment. 
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Code  Extensiors  in  an  8-bit  Environment 
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The  standard  defines  two  terms  for  use  in  describing  code  extension  practices:  to  designate  and  to 
invoke.  They  are  defined  as  follows: 
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to  designate:  To  identify  a set  of  characters  that  are  to  be  represented,  in  some  cases  immediately  and  in 
others  on  the  occurrence  of  a further  control  function,  in  a prescribed  manner. 

to  invoke;  To  cause  a designated  set  of  characters  to  be  represented  by  the  prescribed  bit  combinations 
whenever  those  bit  combinations  occur,  until  an  appropriate  code  extension  function  occurs. 

Designation  of  a character  set  is  usually  achieved  by  employing  an  escape  sequence  defined  by  the 
standard  along  with  values  assigned  by  a registration  authority.  In  many  cases,  designation  of  a character 
set  also  implies  invocation,  in  other  cases  a character  set  must  be  explicitly  invoked  usually  by  using  a shift 
function. 

The  following  table  defines  the  use  of  the  locking  shift  functions  in  an  8-bit  environment  for  extension  of 
the  graphic  set. 
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Function 

Abbreviation 

Set 

Invoked 

Columns 

affected 

LOCKING-SHiFT  ZERO 

LSO 

GO 

02  to  07 

LOCKING-SHIFT  ONE 

LSI 

G1 

02  to  07 

LOCKING-SHIFT  ONE  RIGHT 

LS1R 

G1 

lOto  15 

LOCKING-SHIFT  TWO 

LS2 

G2 

02  to  07 

LOCKING-SHiFT  TWO  RIGHT 

LS2R 

G2 

10  to  15 

LOCKING-SHIFT  THREE 

LS3 

G3 

02  to  07 

LOCKING-SHIFT  THREE  RIGHT 

LS3R 

G3 

10  to  15 

The  meanings  of  control  characters  in  columns  00,  01 , 08  and  09  shall  not  be  affected  by  the  occurrence 
of  these  locking  shift  functions. 

Clause  6.4  states  that  at  the  beginning  of  any  information  interchange,  except  where  interchanging 
parties  have  agreed  otherwise,  all  designations  shall  be  defined  by  the  use  of  appropriate  escape 
sequences,  and  the  shift  status  shall  be  defined  by  the  use  of  the  appropriate  locking  shift  functions. 

A. 7.4.  Announcement  of  ExtensSon  FacOitles 

A code  extension  facility  consists  of  the  elements  of  code  extension  employed  as  well  as  the  means  by 
which  these  elements  are  designated  and  invoked.  Thus  the  control  function  sets,  the  graphic  character 
sets,  and  the  character  shifting  codes  must  be  specified.  Specification  of  control  function  sets  and 
graphic  character  sets  also  specifies  the  designation  and  invocation  sequences  required  to  use  their 
codes. 

Clause  9 of  ISO  2022  describes  how  the  various  extension  facilities  are  to  be  made  known.  If  an 
announcement  is  to  be  embedded  in  the  interchanged  information,  the  form  is  described.  The 
announcement  may  be  omitted  by  agreement  between  the  interchanging  parties.  Some  restrictions  are 
imposed  on  the  defined  announcer  sequences.  For  example  the  sequence  ESC  02/00  04/03  specifies 
that  1)  the  GO  and  G1  sets  shall  be  used  in  an  8-bit  environment  only,  2)  the  designating  escape 
sequences  also  invoke  the  GO  and  G1  sets  into  columns  02  to  07  and  10  to  15,  respectively,  and  3)  no 
locking  shift  functions  shall  be  used. 


A.7.5.  Composite  Graphic  Characters 

Clause  6.1.8  of  the  standard  addresses  methods  for  the  representation  of  additional  graphic  characters  by 
the  combination  of  two  or  more  graphic  characters  in  the  same  position.  Two  methods  are  provided  for: 

a)  graphic  characters  having  implicit  forward  motion  (spacing  characters)  used  in  conjunction  with 
BACKSPACE  or  CARRIAGE  RETURN; 

b)  graphic  characters  having  no  implicit  forward  motion  (non-spacing  ctiaracters)  used  in 
combination  with  spacing  graphic  characters. 

Method  b allows  for  the  specification  of  characters  with  diacritical  marks.  The  technique  is  known 
colloquially  as  the  "dead  key"  approach.  A non-spacing  accent  grave  character  is  immediately  followed  by 
the  cliaracter  it  modifies. 

A.7.6.  International  Register  of  Coded  Character  Sets  to  be  used  with  Escape 
Sequences 

ISO  2375  specifies  procedures  to  be  used  to  assign  meanings  to  the  final  bit  combinations  of  escape 
sequences  defined  in  ISO  2022.  The  Internationa!  Register  of  Coded  Character  Sets  to  be  used  with 
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escape  sequences  is  the  document  which  records  these  assignments.  The  current  International 
Registration  Authority  for  ISO  2375  is  the  European  Computer  Manufacturers  Association  (ECMA). 

A.8.  Character  Sets 

Several  character  set  standards  are  described  here.  The  standards  chosen  for  description  are  each  used 
by  one  or  more  known  OSi  applications.  The  usage  of  these  standards  is  summarized  in  tabular  form. 

A.8.1.  ISO  646  7-bli  cod&d  character  set  for  information  processing  interchange  and 
CCSTT  Recommendation  T.50  international  Alphabet  No.  5 

This  Internationa!  Standard  specifies  a set  of  1 28  characters  with  their  coded  representation.  The  1 28  bit 
combinations  of  the  7-bit  code  represent  control  characters  and  graphic  characters.  The  allocation  of 
characters  to  bit  combinations  is  based  on  the  following  principles: 

• the  bit  combinations  0/0  to  1/15  represent  32  control  characters; 

• the  bit  combination  2/0  represents  the  character  SPACE,  which  is  interpreted  as  both  a control 
character  and  a graphic  character; 

• the  bit  combinations  2/1  to  7/14  represent  up  to  94  graphic  characters; 

• the  bit  combination  7/15  represents  the  control  character  DELETE. 

The  7-bit  code  table  consists  of  128  positions  arranged  in  8 columns  and  16  rows.  The  columns  are 
numbered  from  0 to  7,  and  the  rows  are  numbered  0 to  15. 

Most  of  these  characters  are  mandatory  and  unchangeable,  but  provision  is  made  for  some  flexibility  to 
accommodate  national  and  other  requirements.  The  standard  provides  guidance  on  how  to  exercise  the 
options  offered  in  order  to  define  specific  national  versions  and  application-oriented  versions.  It  further 
specifies  an  international  Reference  Version  in  which  all  options  have  been  exercised. 

«Editor's  Note:  A revision  of  ISO  646  which  has  achieved  DP  status  revises  this  table. » 
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ISO  646  International  Reference  Version 

A.8.2.  8SO  8859  Information  Processing  — 8‘blt  single-byte  coded  character  sets 

This  International  Standard  is  a multiple  part  standard.  Each  part  specifies  a set  of  up  to  191  graphic 
characters  and  the  coded  representation  of  each  of  these  characters  by  means  of  a single  8-bit  byte.  The 
use  of  control  functions  for  the  coded  representation  of  composite  characters  is  prohibited.  Each  set  is 
intended  for  a group  of  languages.  Part  1 of  ISO  8859  specifies  a set  of  191  graphic  characters  identified 
as  Latin  alphabet  No.  1 . This  set  of  graphic  characters  is  suitable  for  use  in  a version  of  an  8-bit  code 
according  to  ISO  2022. 

The  standard  specifically  notes  that  it  is  not  intended  for  use  with  CCITT  defined  Telematic  services.  If 
information  coded  according  to  ISO  8859  is  to  be  transferred  to  such  services,  it  will  have  to  conform  at  the 
coding  interface  to  their  requirements. 

ISO  8859/1-1987  Latin  Alphabet  No.  1 


ISO  8859/1  - 1 987  Latin  Alphabet  No.  1 

A. 8.3.  ISO  6937  Information  Processing  — Coded  Character  Sets  for  Text 
Communication 

This  Internationa!  Standard  specifies  repertoires  of  graphic  characters  and  control  functions,  and  their 
coded  representation  for  use  in  text  communication.  This  International  Standard  consists,  at  present,  of 
two  parts,  as  follows: 

• ISO  6937/1,  General  Introduction. 

• ISO  6937/2,  Latin  Alphabetic  and  non-alphabetic  graphic  characters. 
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The  specifications  are  based  on  the  7-bit  coded  character  set  specified  in  ISO  646,  the  7-bit  and  8-bit 
code  extension  techniques  of  ISO  2022,  and  the  definitions  of  additional  control  functions  given  in  ISO 
6429. 

ISO  6937  was  developed  in  parallel  with  CCITT  Recommendations  Vt/hich  in  the  standard  are  referred  to  as 
S.61  and  S.100.  These  CCITT  Recommendations  were  moved  to  a new  section  in  1984  and  were 
renumbered  T.61  and  T.100.  This  1984  designation  is  being  carried  forward  in  the  1988  CCITT 
Recommendations. 

A.8.3.1.  fSO  6937/1  Snformatlon  Ptocessing  — Coded  Character  Sets  for  Text 
Communication  — Part  1:  General  introduction 

Annex  A of  this  Internationa!  Standard  describes  a method  of  identification  of  graphic  characters  and 
control  functions  which  is  used  in  other  parts  of  the  standard  to  define  the  characters  of  the  standard. 

A.8.3.2,  ISO  6937/2  Information  Processing  — Coded  Character  Sets  for  Text 
Communication  — Part  2:  Latin  Alphabetic  and  Ncn-alphabetic  Graphic  Characters 

This  part  of  the  standard 

defines  a repertoire  of  Latin  alphabetic  and  non-alphabetic  characters  for  the  communication  of 
text  in  European  languages; 

b)  specifies  coded  representations  for  the  graphic  characters; 

c)  specifies  rules  for  the  definition  and  use  of  graphic  character  subrepertoires. 

A graphic  subrepertoire  is  a subset  of  the  defined  character  repertoire.  Because  the  number  of  characters 
defined  by  this  standard  is  so  large,  this  subsetting  facility  allows  for  the  use  of  well  defined  subsets  of  the 
characters  available.  Rules  for  the  definition  of  subrepertoires  are  defined  in  clause  5.  The  procedure  tor 
registration  of  subrepertoires  is  given  in  ISO  7350.  Three  standard  subrepertoires  are  defined  in  Annex  A 
of  the  standard. 

Graphic  characters  which  represent  accented  letters  and  umlauts  are  specified  using  a two  byte  sequence 
composed  of  the  diacritical  character  immediately  followed  by  the  character  modified.  The  allowable 
combinations  are  carefully  defined  in  the  standard  and  only  these  combinations  are  permitted. 


21-20 


Character  Set  Agreements 


March  1990  (Working) 
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A.8.4.  CCSTT  Recommendation  T.51  Coded  Character  Sets  for  Telematic  Services 

This  Recommendation  specifies  a primary  set  and  a supplementary  set  of  graphic  characters  which  are  to 
be  the  respective  supersets  of  various  primary  and  supplementary  character  sets  to  be  used  in  various 
telematic  services.  The  Recommendation  also  describes  those  code  extension  mechanisms  which  are 
relevant  to  existing  telematic  services 

A,8.5.  CCITT  Recommendation  T.61  Character  Repertoire  and  Coded  Character  Sets 
for  the  International  Teletex  Service 

This  Recommendation  contains  detailed  definitions  of  the  repertoires  of  graphic  characters  and  control 
functions  to  be  used  in  the  basic  International  Teletex  service,  and  their  coded  representations  for 
communication. 

A.9.  ASN.1  Character  String  Types 

Character  String  Types  are  sequences  of  zero,  one  or  more  characters  from  some  specified  character  set. 
ISO  8824  defines  8 such  types;  NumericString,  PrintableString,  TeletexString  (T61String), 
Videotexstring,  VisibleString  (IS0646String),  lASString,  Graphicstring,  GeneraiString. 

A.9.1.  Universal  Class  Mumbers  and  Registration  Numbers 
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The  type  of  each  character  string  is  identified  by  a Universal  Class  number.  Universal  Class  numbers  are 
assigned  by  ISO  8824.  No  other  standard  or  private  user  may  define  these  numbers.  The  character  sets 
associated  with  each  type  are  identified  by  the  ISO  Character  Set  Registration  Numbers  as  shown  in  the 
following  table; 


Name  of  Character 
String  Type 

Universal 

Class 

Number 

ISO  Character  Set  Registration  Numbers  j 

NumericString 

18 

Not  Registered 

PrintableString 

19 

Not  Registered 

TeletexString 
(T61  String) 

20 

87,  102,  103,  106,  107  + SPACE  + DELETE 

Videotexstring 

21 

1,  72.  73,  102,  108,  128,  129  + SPACE  + DELETE 

VisibieString 

(IS0646StrinQ) 

26 

2 + SPACE 

lASString 

22 

1,2  + SPACE  + DELETE 

Graphicstring 

25 

All  G sets  + SPACE 

Generalstring 

27 

All  G sets  and  all  C sets  + SPACE  + DELETE 

Numericstring  and  PrintableString  do  not  have  Registration  Numbers  assigned  to  them  since  their 
character  sets  are  defined  in  table  4 and  5 respectively  of  ISO  8824. 

A. 9. 2.  Initial  States 

Some  character  string  types  allow  multiple  character  sets  through  code  extension  techniques.  For  these 
types,  at  the  beginning  of  each  string  there  are  initial  default  character  sets  to  be  designated  in  GO  and/or 
CO  and/or  Cl  and  for  each  character  set  there  is  an  assumed  escape  sequence.  The  following  table 
drawn  from  ISO  8826  describes  these  initial  states. 


Name  of 
Character 
String  Type 

initial  GG 
(Reg.  No.) 

Initial  CO 
(Reg.  No.) 

Initial  C1 
(Reg.  No.) 

initial  ESC  Seq 
and  Lock  Shift 
Function 

Cod© 

Extension 

Numericstring 

2 

None 

None 

ESC  2/8  4/0  LSO 

No 

PrintableString 

2 

None 

None 

ESC  2/8  4/0  LSO 

No 

TeletexString 
(T61  String) 

102 

106 

107 

ESC  2/8  4/0  LSO 
ESC  2/1  4/5 

ESC  2/2  4/8 

Yes 

Videotexstring 

102 

1 

73 

ESC  2/8  7/5  LSO 
ESC  2/1  4/0 

ESC  2/2  4/1 

Yes 

VisibieString 

(IS0646String) 

2 

None 

None 

ESC  2/8  4/0  LSO 

No 

lASString 

2 

1 

None 

ESC  2/8  4/0  LSO 
ESC  2/1  4/0 

No 

Graphicstring 

2 

None 

None 

ESC  2/8  4/0  LSO 

Yes 

Generalstring 

2 

1 

None 

ESC  2/1  4/0  LSO 
ESC  2/1  4/0 

Yes 

For  example,  Videotexstring  initial  GO  set  is  Primary  Teletex  Graphic  Set  (ISO  Registration  Number  102), 
initial  CO  set  is  ISO  646  CO  set  (ISO  Registration  Number  1),  initial  C1  set  is  Attribute  Control  Set  for 
Videotex  (ISO  Registration  Number  73),  initial  escape  sequence  and  locking  shift  function  is  ESC  2/8  7/5 
LSO,  and  ESC  2/2  4/1 , and  code  extensions  are  permitted. 

A. 10.  Use  of  ASM.1  OctetStrirag  as  a Character  String 

«Editor’s  Note:  Add  a description  of  ODA  treatment  of  character  $ets.» 
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A.11.  Escape  Sequences  for  Character  Set  Designation 

This  information  is  extracted  from  the  ISO  Register.  In  some  cases,  the  defaults  supplied  by  ASN.1  make 
the  use  of  these  escape  sequences  unnecessary.  In  some  cases,  this  information  is  carried  by  application 
protocol  elements. 

Graphic  Set  Designation 


Set  No. 

GO 

G1 

G2 

Name 

2 

ESC  2/8  4/0 

ISO  646  IRV 

6 

ESC  2/8  4/2 

ISO  646  USA 

87 

ESC  2/4  2/8  4/2 

ESC  2/4  2/9  4/2 

JIS  X0208 

100 

ESC  2/1 3 4/1 

ESC  2/14  4/1 

ISO  8859/1  Right  Hand  Part 

102 

ESC  2/8  7/5 

CCnTT.61  Primary 

103 

ESC  2/10  7/6 

CCiTTT.61  Supp 

126 

ESC  2/13  4/6 

ISO  8859/7  Greek 

142 

ESC  2/14  4/10  ! ISO  6937/2  Adi  Supp 

Control  Set  Designation 


Set  No. 

CO 

Cl 

Name 

1 

ESC  2/1  4/0 

ISO  646  CO 

106 

ESC  2/1  4/5 

CCITTT.61  Primary 

107 

ESC  2/2  4/8 

CCITTT.61  Suppl. 

«Editor's  Note:  Add  6429  designation.» 
«Editor's  Note:  Add  DIS  10538  amd  DIS  10367?» 
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22.  OFFICE  DOCUMENT  ARCHITECTURE  FOR  RASTER  DOCUMENTS 

This  is  the  definition  of  an  ODA  document  application  profile  (DAP) 
named  NIST  ODA  Level  1 (Raster)  DAP.  This  Document  Application 
Profile  is  suitable  for  interchanging  a document  containing  raster 
content  in  formatted  processable  form.  This  Document  Application 
Profile  has  been  prepared  by  the  ODA  Special  Interest  Group  of  the 
NIST  OSI  Implementors  Workshop  (OIW) . The  Document  Application 
Profile  is  defined  in  accordance  with  IS  8613-1  and  CCITT  T.411  and 
follows  the  standardized  proforma  and  notation  defined  in  ISO  8613-1 
proposed  Draft  Addendum  (to  be  published).  The  Document  Application 
Profile  is  based  on  ODA  as  defined  in  IS  8613  and  the  Raster  Graphics 
Content  Architecture  of  IS  8613,  Part  7. 


22.1  SCOPE  AND  FIELD  OF  APPLICATION 


This  document  application  profile  specifies  an  interchange  format 
suitable  for  transfer  of  structured  documents  containing  raster 
graphics,  such  as  engineering  drawings  and  illustrations,  implemented 
either  with  or  without  the  use  of  the  tiled  raster  content. 

This  document  defines  a document  application  profile  that  allows  large 
format  raster  documents  to  be  interchanged  in  a formatted  processable 
form  in  accordance  with  ISO  8613. 

This  document  application  profile  is  designed  to  be  independent  of  the 
means  used  to  create  or  to  interchange  the  encoded  documents. 

It  is  assumed  that,  when  negotiation  is  performed  by  the  service  using 
this  document  application  profile,  all  non-basic  features  are  subject 
to  negotiation. 

This  document  application  profile  is  independent  of  the  processes 
carried  out  in  an  end  system  to  create,  edit,  or  reproduce  which,  for 
example,  may  be  by  means  of  communication  links  or  storage  media. 

The  features  of  a document  which  can  be  interchanged  using  this 
document  application  profile  fall  into  the  following  categories: 

Page  format  features  - these  concern  how  the  layout  of  each  page 
of  a document  will  appear  when  reproduced; 

Raster  graphics  layout  and  imaging  features  - these  concern  how 
the  document  content  will  appear  within  pages  of  the  reproduced 
document ; and 
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Raster  graphics  coding  - these  concern  the  raster  graphics 
representations  and  control  functions  that  make  up  the  document 
raster  graphics  content. 

22.2  REFERENCES 


The  following  references  are  required  in  order  to  implement  this 
document  application  profile: 

ISO  8613-1  - Information  processing:  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  1: 
Introduction  and  General  Principles 

ISO  8613-2  - Information  processing:  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  2:  Document 
Structures 

ISO  8613-4  - Information  processing:  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  4:  Document 
Profile 

ISO  8613-5  - Information  processing:  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  5:  Office 
Document  Interchange  Format 

ISO  8613-7  - Information  processing:  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  7:  Raster 
Graphics  Content  Architectures 

ISO  8613-7  - Draft  Addendum:  Tiled  Raster  Graphics  Addendum  to  ISO 
8613,  Part  7 

ISO  8613-1  - Draft  Addendum:  Document  Application  Profile  Proforma  and 
Notation  (to  be  published) 

ISO  8824  - Information  Processing  Systems  - Open  Systems 
Interconnection  - Specification  of  Abstract  Syntax  Notation  One 
(ASN. 1) 

ISO  8825  - Information  Processing  Systems  - Open  Systems 
Interconnection  - Specification  of  Basic  Encoding  Rules  for  Abstract 
Syntax  Notation  One  (ASN.l) 

CCITT  T.6  - Facsimile  Coding  Schemes  and  Coding  Control  Functions  for 
Group  4 Facsimile  Apparatus,  1984 

CCITT  T.411  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Introduction  and  general  principles,  1988 
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CCITT  T.412  Open  Document  Architecture  (ODA)  and  Interchange  Format 
Document  structures,  1988 

CCITT  T.414  Open  Document  Architecture  (ODA)  and  Interchange  Format 
Document  profile,  1988 


CCITT  T.415  Open  Document  Architecture  (ODA)  and  Interchange  Format 
Open  document  interchange  format,  1988 

CCITT  T.417  Open  Document  Architecture  (ODA)  and  Interchange  Format 
Raster  graphics  content  architecture,  1988 


CCITT  T,502  Document  Application  Profile  PM.l  for  the  interchange  of 
processable  form  documents 


22.3  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 

The  following  additional  definitions  are  applicable  to  this  document. 

Generating  Support  Statement  (CSS) 

A statement  which  states  the  range  of  support  of  an  originating 
system.  An  originating  system  generates  ODIF  data  streams.  A GSS 
defines  a subset  of  all  possible  data  streams  supported  by  an 
implementation  which  an  origination  capability.  A GSS  is 
specified  by  completing  the  GSSP  defined  in  Annex  A of  this 
document . 

Generating  Support  Statement  Proforma  (GSSP) 

A definition  of  the  conformance  requirements  of  a profile  in  terms 
of  a list  of  requirements  for  implementations  to  originate  data 
streams  which  conform  to  the  profile.  A GSSP  defines  the  format 
for  all  GSSs. 

Receiving  Support  Statement  (RSS) 

A statement  which  states  the  range  of  support  of  a receiving 
system.  A receiving  system  interprets  ODIF  data  streams.  A RSS 
defines  functions  and  fall-backs  supported  by  an  implementation 
with  a reception  capability.  A RSS  is  specified  by  completing  the 
RSSP  defined  in  Annex  A of  this  document. 

Receiving  Support  Statement  Proforma  (RSSP) 
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A definition  of  the  conforiaance  requirements  of  a profile  in  terms 
of  a list  of  requirements,  including  fall-backs,  for 
implementations  to  receive  data  streams  which  conform  to  the 
profile,  A RSSP  defines  the  format  for  all  RSSs. 


22.4  POSITION  OF  THIS  DAP  IN  THE  TAXONOMY  OF  RELATED  DAPS 


There  are  several  regional  activities  involving  the  development  of  ODA 
document  application  profiles  other  than  the  NIST  ODA  SIG.  These 
include  the  following: 

Asia-Oceania  Workshop  (AOW)  ODA  SIG 

CCITT  Study  Group  VIII,  Question  26 
European  Workshop  for  Open  Systems  ODA  EG 

Profile  Alignment  Group  for  ODA  (PAGODA) 


22,4. lAOW  ODA  SIG 


This  document  application  profile  is  a functional  subset  of  the  AOW 
AE-1126  document  application  profile.  This  document  application 
profile  is  a functional  superset  of  the  AOW  AE-1111  and  AE-1116 
document  application  profiles. 


22.4.2CCITT  SG  VIII.  Q26 

This  document  application  profile  is  expected  to  be  a functional 
subset  of  the  CCITT  "pm3"  document  application  profile.  This  document 
application  profile  is  expected  to  be  functionally  equivalent  to  the 
CCITT  ''pm2"  document  application  profile.  This  document  application 
profile  is  a functional  superset  of  the  CCITT  T.502  Recommendation, 


22.4.3EWOS  ODA  EG 


This  document  application  profile  is  expected  to  be  a functional 
subset  of  the  EWOS  Q113  docxoment  application  profile.  This  document 
application  profile  is  a functional  superset  of  the  EWOS  Qlll  dociiment 
application  profile.  This  document  application  profile  is  expected  to 
be  equivalent  to  the  EWOS  Q112  document  application  profile. 


22-4 


March  1990  (Working) 


22.4.4NIST  PDA  SIG 

There  are  three  document  application  profiles  developed  by  the  NIST 
ODA  SIG.  These  are  named  the  NIST  Level  1 (Raster),  Level  2,  and 
Level  3 DAPs.  This  profile  is  a subset  of  the  NIST  Level  2 and  Level 
3 DAPs. 

The  NIST  Level  2 DAP  provides  for  the  interchange  of  multi-media 
documents  between  advanced  document  processing  systems  within  an 
integrated  office  environment.  The  NIST  Level  3 DAP  provides  for  the 
Interchange  of  a wide  range  of  documents  from  simple  documents  to 
highly  structured  technical  reports,  articles  and  typeset  documents 
such  as  brochures.  Documents  in  both  levels  may  contain  characters, 
raster  (tiled  and  untiled)  graphics,  and  geometric  graphics  content. 


22.4.5PAGODA 

There  are  three  document  application  profiles  developed  by  PAGODA  for 
submission  as  ISPs.  These  are  named  Core-11,  Core-26  and  Core-36. 

22,5  CONFORMANCE 

In  order  to  conform  to  this  document  application  profile,  a data 
stream  representing  a document  must  meet  the  requirements  specified  in 
subclause  1. 

Subclause  2 specifies  the  requirements  for  implementations  that 
originate  and/or  receive  data  streams  conforming  to  this  document 
application  profile. 


22.5.lData  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that 
conform  to  these  agreements. 

Tlie  data  stream  shall  be  encoded  in  accordance  with  the  ASN.l 
encoding  rules  defined  in  ISO  8825, 

The  data  stream  shall  be  structured  in  accordance  with  the 
interchange  format  defined  in  clause  22.8  of  this  document 
application  profile. 

The  encoded  document  shall  be  structured  in  accordance  with  one 
of  the  document  architecture  classes  specified  in  clause  22.7 
of  this  docu5.ient  application  profile.  In  addition,  the  encoded 
document  shall  contain  all  required  constituents  specified  for 
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that  class  and  contain  only  constituents  permitted  or  required 
for  that  class  as  specified  in  clause  22.7  of  this  document 
application  profile, 

The  encoded  constituents  shall  contain  all  required  attributes 
as  specified  in  clause  22.7  of  this  document  application 
profile , 

The  encoded  attributes  shall  have  values  within  the  range  of 
permissible  values  specified  in  clause  22.7  of  this  document 
application  profile, 

The  encoded  document  shall  be  structured  in  accordance  with  the 
abstract  document  architecture  defined  in  ISO  8613, 

The  encoded  document  shall  be  structured  in  accordance  with  the 
characteristics  defined  in  clause  22.6  of  this  document 
application  profile. 

22.5. 2lmplementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming 
conformance  to  this  document  application  profile. 

An  implementation  claiming  to  originate  and/or  receive  data  streams 
conforming  to  this  document  application  profile  must  complete  a 
Generator  Support  Statement  (GSS)  and/or  Receiver  Support  Statement 
(RSS)  Proforma  as  defined  in  section  22.9  of  this  document  application 
profile . 

A conforming  receiving  implementation  must  be  capable  of  receiving  any 
data  stream  conforming  to  this  document  application  profile. 
"Receiving"  means  not  rejecting  a data  stream  conforming  to  this 
document  application  profile  and  usually,  but  not  always,  involves 
recognizing  and  further  processing  the  data  stream  elements.  The 
explicit  meaning  of  "receiving"  is  determined  by  a RSS  defined  in 
accordance  with  section  22.9  of  this  document  application  profile. 


22.6  CHARACTERISTICS  SUPPORTED  BY  THIS  DAP 


22.6. lOverview 


This  document  application  profile  describes  the  features  of  ISO  8613 
that  are  need  to  support  the  interchange  of  documents  containing  only 
raster  content.  It  specifies  interchaxige  formats  for  the  transfer  of 
structured  documents  with  simple  logical  and  layout  structures. 
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This  document  application  profile  describes  documents  which  can  be 
interchanged  in  the  formatted-processable  form  as  defined  in  ISO  8613. 

Only  one  category  of  content  is  allowed  within  the  same  page,  namely, 
a raster  graphics  content. 

This  section  describes  the  logical  characteristics  and  layout  features 
that  can  be  represented  in  documents  conforming  to  this  document 
application  profile.  The  features  are  described  in  terms  that  are 
typical  of  the  user-perceived  capabilities  and  semantics  found  in 
current  document  processors. 

The  required  constituents  include: 

- a document  profile, 

- logical  object  descriptions  representing  a specific 
logical  structure, 

- layout  object  descriptions  representing  a specific  layout 
structure,  and 

- presentation  styles. 

22 . 6 ■ 2Logical  Characteristics 

The  following  section  describes  the  logical  features  that  can  be 
represented  in  documents  conforming  to  this  document  application 
profile . 


22 ■ 6 . 2 . ILogical  Structure  Summary 

A logical  structure  of  the  document  conforming  to  this  application 
profile  consists  of  a three  level  hierarchy  of  a document  logical 
root,  a composite  logical  object  (Passage),  and  the  basic  logical 
object  (Body  Raster).  The  following  is  a logical  structure  derived 
from  this  document  application  profile: 

Document  Logical  Root 
Passage 

Body  Raster 
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22 ■ 6 . 2 . 2Document  Logical  Root 
The  logical  view  of  a dociiraent  is  composed  of  a Passage. 

22.6.2, 3Passage 

A Passage  is  a composite  logical  object  that  consists  of  the  Body 
Raster . 


22.6.2.4Bodv  Raster 

A Body  Raster  is  a basic  logical  object  that  defines  a raster  graphics 
content  architecture  content  portion  that  appears  in  the  body  area  of 
the  document . 

22.6.3Lavout  Characteristics 

The  following  section  describes  the  layout  features  that  can  be 
represented  in  documents  conforming  to  this  document  application 
profile . 


22 . 6 . 3 ■ ILayout  Structure  Summary 

A layout  structure  of  the  document  conforming  to  this  application 
profile  consists  of  a four  level  hierarchy  of  a document  layout  root, 
a page  set,  and  a page  with  a single  frame  containing  the  basic  layout 
object  (Basic  Body). 

The  following  is  a document  layout  structure  derived  from  this 
document  application  profile: 

Document  Layout  Root 
Page  Set 
Page 

Basic  Body 


22 . 6 . 3 . 2Document  Layout  Root 
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The  layout  view  of  a document  is  composed  of  an  ordered  sequence  of 
one  or  more  page  sets. 


22.6.3.3Page  Set 

A Page  Set  is  a composite  layout  object  that  represents  a collection 
of  pages.  A Page  Set  consists  of  a sequence  of  repeated  pages  with 
the  same  layout  format. 

The  pages  within  a Page  Set  must  have  the  same  dimensions  and 
orientation  (i.e.,  landscape  or  portrait). 


22.6.3.4Page 

A Page  is  a composite  layout  object  that  corresponds  to  the  area  used 
for  presenting  the  content  of  the  document.  A Page  consists  of  a 
Basic  Body  frame. 

Various  page  dimensions  are  supported.  The  default  dimensions  are  the 
common  assured  reproduction  are  (CARA)  of  ISO  A4  and  North  American 
Letter  (A) . The  non-basic  dimensions  of  ISO  A0-A3  and  North  American 
B-L  are  supported.  Both  portrait  and  landscape  orientations  are 
supported . 

22 ■ 6 ■ 3 . SBasic  Body 

A Basic  Body  is  a basic  layout  object  that  defines  a region  of  the 
page  to  contain  body  area  contents.  The  Basic  Body  consists  of  a 
single  subordinate  block  of  content  where  the  dimension  is  the  same  as 
the  Page  dimension. 


22 . 6 .4Document  Layout  Characteristics 

A document  layout  structure  contains  a page  which  contains  a frame 
with  a block  of  raster  graphics  content. 

A document  consists  of  only  a single  page  set. 

This  document  application  profile  supports  various  page  dimensions 
including  the  nominal  page  sizes  of  the  North  American  A-K  and  ISO  A4- 
AO  formats.  The  standard  default  is  the  nominal  page  size  of  the  ISO 
A4  and  North  American  Letter  (A) . 

A page  containing  tiled  raster  graphics  content  may  consist  of  as  many 
tiles  as  is  necessary  to  represent  the  image  in  digital  form. 
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22 . 6 ■ SContent  Layout  and  ImaEing  Characteristics 

The  content  characteristics  of  this  document  application  profile  will 
contain  only  raster  data.  Only  the  CCITT  Recommendation  T.6  Group  4 
compression  algorithia  shall  be  used  except  where  it  is  more  efficient 
to  retain  a tile  image  in  bit-map  format  or  to  specify  a tile  as  being 
either  all  background  or  all  foreground. 

Tiled  raster  graphics  is  defined  by  the  type  of  coding  and  the 
dimensions  of  the  array  of  picture  elements  (pels).  The  attributes  to 
define  the  contents  are  specified  in  ISO  8613-7  and  the  "Addendum." 

The  presentation  of  the  raster  graphics  content  block  is  controlled  by 
the  presentation  style  containing  the  presentation  attributes 
specified  in  ISO  8613-7  and  the  "Addendum." 


22 ■ 6 . 6MisceIlaneous  Features 


There  are  no  features  described  in  this  clause. 

22 . 6 ■ 7Document  Management  Features 

Every  document  interchanged  in  accordance  with  this  document 
application  profile  must  include  a docximent  profile  containing 
information  which  relates  to  the  document  as  a whole.  The  document 
profile  used  in  this  document  application  profile  must  identify  the 
contents  as  raster  graphics  data. 

The  features  specified  by  the  document  profile  are  listed  below.  A 
definition  of  the  information  contained  in  these  features  is  given  in 
the  corresponding  attribute  definitions  in  ISO  8613-4. 

Presence  of  document  constituents: 

- specific  layout  structure; 

- specific  logical  structure; 

- presentation  styles. 

Document  characteristics: 

- document  application  profile; 

- document  application  profile  defaults; 

- docioment  architecture  class; 

- content  architecture  class; 

- interchange  format  class; 

- ODA  version  date. 
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Non-basic  docixinent  characteristics: 

- page  dimensions; 

- medium  type , 

The  document  characteristics  attributes  listed  above  are 
mandatory. 


22.7  SPECIFICATION  OF  CONSTITUENT  CONSTRAINTS 


22 ■ 7 . iDocument  Profile  Constraints 


22 ■ 7 . 1 . IMacro  Definitions 

DEFINE(BASIC-PAG-DIM,  ’’ 

Common  Assured  Reproduction  Areas  (CARA) 

#horizontal{ 9240 . . 39732 ) ,#vertical{ 12400 .. 56173 } , | 

CARA  of  ISO  A4  and  ANSI  A portrait  <=  ISO  AO  portrait 
#horizontaI{ 12400 .. 56173 ) , #vertical  { 9240 39732 ) , j 
CARA  of  ISO  A4  and  ANSI  A landscape  <=  ISO  AO  landscape 
#horizontal{ 9240 , . 39600 ) ,#verticali 12400 , . 52200} , j 
CARA  of  ISO  A4  and  ANSI  A portrait  <=  ARA  ANSI  E portrait 
#horizontal{ 12400 . . 52200] ,#vertical{ 9240 . . 39600) 

CARA  of  ISO  A4  and  ANSI  A landscape  <=  ARA  ANSI  E landscape- - 

") 

DEFINE(NON-BASIC-PAG-DIM, " 

Assured  Reproduction  Areas  (ARA) 

#horizontal{ 13200} ,#vertical{ 18480} 

--  ARA  ISO  A3  Portrait  (279mm  x 391mm)  -- 

#horizontal{ 18840} ,#vertical{ 13200} | 

ARA  ISO  A3  Landscape  (420ffim  x 297mm) 

#horizontal{  12744}  ,#\^ertical { 19656 } | 

ARA  ANSI  B Portrait  (10.62in  x 16.38in) 

#horizontal{ 19656 } ,#vertical{ 12744} 

--  ARA  ASNI  B Landscape  (16.38in  x 10.62in)  --  j 

--  Full  Page  Sizes  -- 

#horizontal{9920} ,#vertical{ 14030} j 
ISO  A4  Portrait  (210mm  x 297ffim) 

#horizontal{ 14030} ,#vertical{ 9920] | 

ISO  A4  Portrait  (297iam  x 210mm) 

#horizontal{ 14030} ,#vertical( 19840} | 


all 
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ISO  A3  Portrait  (297nBBi  x 420nun) 
#horizontal{ 19840) ,#vertical{ 14030) | 
ISO  A3  Landscape  (420nim  x 297iBm) 
#horizontal{  19840)  .^^^erticalj  28060)  \ 
ISO  A2  Portrait  (4203nffi  x 594mm) 
#horizontal{ 28060) ,#vertical{ 19840) j 
ISO  A2  Landscape  (594mm  x 420iiiih) 
#horizontaI{ 28060) ,#vertical{ 39680) | 
ISO  Al  Portrait  (594mm  x 840mffi) 
#horizontal{ 39630) ,#vertical{ 28060) j 
ISO  Al  Landscape  (840mm  x 594mm) 
#horizontal{ 39680) ,#vertical{ 56120) | 
ISO  AO  Portrait  (840mm  x llSSmm) 
#horizontal{56120) ,#vertical{39680) j 
ISO  AO  Landscape  (llSSmm  x 840mra) 
#horizontal{ 10200) ,#vertical{ 13200) j 
ANSI  A Portrait  (8, Sin  x llin) 
#horizontal{ 13200) ,#vertical{ 10200) 
ASNI  A Landscape  (llin  x 8. 5 in) 
#horizontal{ 10200) ,#vertical{ 16800) j 
ANSI  L Portrait  (8.5in  x 14in) 
#horizontal{  16800)  ,#\'’ertlcal{  10200) 
ASNI  L Landscape  (8. Sin  x 814in) 

#hor izontal { 13200 ) , #vertica 1 { 20400 ) j 
ANSI  B Portrait  (llin  x 17in) 
#horizontal{ 20400) ,#vertical{ 13200) 
ASNI  B Landscape  (17in  x llin) 
#horizontal { 20400 ) ,#vertical{ 26400) j 
ANSI  C Portrait  (17in  x 22in) 

#hor izontal { 26400 ) , #vertical { 20400 ) 
ASNI  C Landscape  (22in  x 171n) 
#horizontai{ 26400) ,#vertical{ 40800) j 
ANSI  D Portrait  (22in  x 34in) 
#horizontal { 40800 ) , #vert ical { 26400 ) 
ASNI  D Landscape  (34in  x 22in) 
#horizontal{ 40800)  ,#\>'ertical{  52800)  | 
ANSI  E Portrait  (34in  x 44in) 
#horizontal { 52800 ) , #vertical { 40800 ) 
ASNI  E Landscape  (44in  x 34in) 
#horizontaI{ 33600) ,#vertical{ 48000) | 
ANSI  F Portrait  (28in  x 40in) 
#horizontal{ 48000) ,#vertical{ 33600) 
ASNI  F Landscape  (40in  x 28in) 
#horizontal{ 13200) ,#vertical{ 108000) | 
ANSI  G Portrait  (llin  x 90in) 
#horizontal{ 108000) ,#vertical{ 13200} 
ASNI  G Landscape  (90in  x llin) 
#horizontal{ 33600} ,#vertical{ 171600} | 
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ANSI  H Portrait  (28in  x 143in) 
#horizontal{ 171600} ,#vertical{ 33600) 
ASNI  H Landscape  (143in  x 28in) 
#horizontal {40800 } ,#vertical{211200) | 
ANSI  J Portrait  (34in  x 176in) 
#horizonta.l {211 200 } , #vert ical  { 40800 ) 
ASNI  J Landscape  (176 in  x 34 in) 
#horizontai {48000} ,#vertical{ 171600} | 
ANSI  K Portrait  (40in  x 143in) 
#horizontal { 171600} ,#vertical{ 48000} 
ASNI  K Landscape  (1431n  x 40in) 

’’) 

DEFINE(NON-BASIC-NOM-PAG-SIZ, " 

#horizontal { 9920 } ,#vertical{ 14030} | 
ISO  A4  Portrait  (210niiit  x 297111®) 
#horizontal{ 14030} ,#vertical{9920} j 
ISO  A4  Portrait  (297®®  x 210®®) 
#horizontal{ 14030} ,#vertical{ 19840} | 
ISO  A3  Portrait  (297®m  x 420mm) 
#horizontal{ 19840) ,#vertical{ 14030} | 
ISO  A3  Landscape  (420iraii  x 297mm) 
#horizontal{ 19840} ,#vertical{28060} j 
ISO  A2  Portrait  (420m®  x 594nrai) 
#horizontal{ 28060} ,#vertical{ 19840) j 
ISO  A2  Landscape  (594mm  x 420mm) 
#horizontal{ 28060} ,#vertical{ 39680} | 
ISO  Al  Portrait  (594mm  x 840mm) 
#horizontal { 39680} ,#vertical{ 28060} j 
ISO  Al  Landscape  (840mm  x 594mm) 
#horizontal{ 39680} ,#vertical{ 56120} | 
ISO  AO  Portrait  (840mm  x 1188mm) 
#horizontal { 56120 } ,#vertical{ 39680} | 
ISO  AO  Landscape  (1188mm  x 840mra) 
#horizontal{ 10200} ,#vertical{ 13200} | 
ANSI  A Portrait  (8,5in  x llin) 
#horizontal{ 13200} ,#vertical{ 10200} 
ASNI  A Landscape  (llin  x 8. 5 in) 
#horizontal{ 10200} ,#vertical{ 16800}  | 
ANSI  L Portrait  (8.5in  x 14in) 
#horizontal( 16800} ,#vertical{ 10200} 
ASNI  L Landscape  (8.5in  x 814in) 
#horizontal { 1 3200 } , #vertical { 20400 } | 
ANSI  B Portrait  (llin  x 17 in) 
#horizontal { 20400 } ,#vertical{ 13200} 
ASNI  B Landscape  (17in  x llin) 
#horizontal{ 20400} ,#vertical{ 26400} j 
ANSI  C Portrait  (17in  x 22in) 
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#horizontal { 26400 ) , #vertical { 20400 ) 

ASNI  C Landscape  (22in  x 17in) 

#horizontal { 26400 } ,#vertical{40800) | 

ANSI  D Portrait  (22in  x 34in) 

#horizontal{ 40800} ,#vertical{ 26400} 

ASNI  D Landscape  (34in  x 22in) 
#horizontal{ 40800} ,#vertical( 52800} j 
ANSI  E Portrait  (34in  x 44in) 

#horizontal{ 52800} ,#vertical{ 40800} 

ASNI  E Landscape  (44 in  x 34in) 
#horizontal{ 33600} ,#vertical {48000} | 

ANSI  F Portrait  (28in  x 40in) 
#horizontal(48000 } ,#vertical{ 33600} 

ASNI  F Landscape  (40in  x 28in) 
#horizontal( 13200} ,#vertical( 108000} | 

ANSI  G Portrait  (llin  x 90in) 

#horizontal{ 108000} ,#vertical( 13200} 

ASNI  G Landscape  (90in  x llin) 
#horizontal( 33600} ,#vertical( 171600} | 

ANSI  H Portrait  (28in  x 143in) 
#horizontal( 171600} ,#vertical( 33600} 

ASNI  H Landscape  (143 in  x 28 in) 
#horizontal( 40800} ,#vertical(211200} | 

ANSI  J Portrait  (34in  x 176in) 
#horizontal( 211200} ,#vertical{ 40800} 

ASNI  J Landscape  (176 in  x 34 in) 
#horizontal{48000} ,#vertical{ 171600} | 

ANSI  K Portrait  (40in  x 143in) 
#horizontal{ 171600} ,#vertical( 48000} 

ASNI  K Landscape  (1431n  x 40in) 

") 

DEFINE(FPDA,"formatted-processable  (2)") 

DEFINE ( DAG, " 

Document-prof ile (#Document- character is tics 
(#Document-architecture-class } } ") 

DEFINE(RFP, "(2  8 2 7 2}")--  Raster  formatted 
processable 

DEFINE ( COMPLETE , "complete-generator-set  (1) ") 

DEFINE(PRESENT, "present  (1)") 
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22 ■ 7 . 1 . 2Constituent  Constraints 


22.7.1.2.1  Presence  of  Document  Constituents 
CASE  {$DAC  OF 
$FPDA: 

REQ  Specific-layout-structure{$PRESENT) ; 

REQ  Specific-logical-structure{$PRESENT) ; 

PERM  Presentation- styles { $PRESENT) ; 

) 


22.7.1.2. 2Document  characteristics 


REQ  Document-application-prof ile { ) ; 

--  Object  ID  needed  for  DAP  -- 

REQ  Doc-appl-prof ile-defaults { 

Document -architecture -defaults 

REQ  #Content-architecture-class { $RFP) , 

PERM  #Page-dimensions { $BASIC-PAG-DIM  | 

$N0N- BASIC -PAG- DIM  | 
$NON-BASIC-NOM-PAG-SIZE} , 

PERM  #Medium- type { 

REQ  #Nominal-page-size { $BASIC-PAG-DIM  | 
$NON-BASIC-PAG-DIM} , 

REQ  #Side-of-sheet{ANY_VALUE} } , 

PERM  Raster-gr-contents-defaults { 

PERM  #Pel-path{ ' 0-degrees ' | '180-degrees'), 
PERM  #Line-progression{ '270-degrees' } , 

PERM  #Pel-spacing{ANY_VALUE  <1200), 

PERM  #Gompression{ 'compressed' ) , 

PERM  #Number-of-pels-per-tile-line{ (512) ) , 

PERM  #Number-of-lines-per-tile  {(512)), 

PERM  #Tiling-offset{ANY_VALUE) ) , 

REQ  Document-architecture-class  {$FPDA); 

REQ  Interchange-format-class { if-a  (0)); 

REQ  ODA-version  { 

REQ  #standard-or-recommendation{ "ISO  8613"), 
REQ  #publication-date{ "1989-07-04" ) ); 

REQ  Non-basic-doc-characteristics ( ( 

REQ  #Page- dimens ions { $BASIC-PAG-DIM| 
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$NON-BASIC-PAG-DIM} , 

REQ  #Mediuin- types  { 

REQ#Nominal-page-size{$NON-BASIC-NOM-PAG-SIZ) , 
REQ#Side-of-sheet{ANY_VALUE) , 

PERM  #Ra- gr-presentat ion- features { 

PERM#Pel-path{ ' 180-degrees ' ) , 
PERM#Line-progression{ ' 90-degrees ' } , 

PERM  #Pel-spacing{ANY_VALUE) , 

PERM#Compression{ 'uncompressed' } ) ; 


22 . 7 . 1 ■ 2 ■ SDocument  Management  Attributes 

PERM  Title {ANY_VALUE ) : 

PERM  Subject{ANY_VALUE) ; 

PERM  Document - type { ANY_VALUE ) ; 

PERM  Abstract {ANY_VALUE ) ; 

PERM  Document-date-and-time{ANY_VALUE) ; 

PERM  Originators{ANY_VALUE} ; 

PERM  Other-user- inf ormation{ANY_VALUE} ; 

PERM  External-references {ANY_VALUE} ; 

PERM  Local-file-references {ANY_VALUE} ; 

PERM  Content-attributes {ANY_VALUE) ; 

PERM  Security- information{ANY_VALUE) ; 


22 ■ 7 . 2Logical  Constituent  Constraints 

Note: The  production  rules  for  the  Generator- for- subordinates 
for  the  logical  constraint  objects  has  not  as  yet  been 
aligned  with  the  notation  used  in  the  PAGODA  DAPs. 

22 ■ 7 ■ 2 . IDiagrams  of  Relationships  of  Logical  Constituents 

The  notation  used  for  the  structure  diagrams  is  that  specified  in 
Appendix  A of  ISO  8613-2. 

The  following  diagrams  represent  the  primary  graph  for  the  logical 
obj  ects . 
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22 ■ 7 . 2 . 2Macro  Definitions 


22 ■ 7 ■ 2 . 3Factor  Constraints 


FACTOR:  ANY -LOGICAL! 

SPECIFIC: 

PERM  Obj ect- type (VIRTUAL) ; 

REQ  Object-identifier{ANY_VALUE) ; 

} 

FACTOR:  COMP -LOG I CAL: ANY -LOGICAL! 

SPECIFIC: 

REQ  Subordinates (VIRTUAL) ; 

PERM  Obj ect- type !C0MP0SITE_L0GICAL_0BJECT) ; 

} 

FACTOR:  BASIC-LOGICAL:ANY-LOGICAL! 

SPECIFIC: 

PERM  Object-type!BASIC_LOGICAL_OBJECT) ; 

PERM  Content-portions !ANY_VALUE) ; 

) 

22 . 7 ■ 2 . 4Constituent  Constraints 


22.7.2.4. ILogDoc : ANY-LOGICAL! 

SPECIFIC: 

REQ  Subordinates ( SUBORDINATE_ID_OF 
(Passage)+) ; 

PERM  Obj  ect- type ( D0CUMENT_L0GICAL_R00T ) 
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22.7.2.4. 2Passage : C0MP-L0GICAL{ 
SPECIFIC: 

REQ  Subordinates { SUBORDINATE_ID_OF 
(BodyRaster) ) ; 

PERM  Application-comments { "Passage" ) ; 


22.7.2.4. 3BodyRaster : BASIC -L0CICAL{ 

SPECIFIC: 

PERM  Content-architecture-class { $RFP) ; 

PERM  Content-portions {CONTENT_ID_OF(RASTER) ) ; 
PERM  Presentation-style { STYLE_ID_0F(PStyle3) ) ; 

PERM  Application-comments { "BodyRaster" } 

) 


22.7.3Lavout  Constituent  Constraints 

Note:The  production  rules  for  the  Generator- for- subordinates 
for  the  layout  constraint  objects  has  not  as  yet  been 
aligned  with  the  notation  used  in  the  PAGODA  DAPs. 

22 . 7 . 3 . IDiagrams  of  Relationships  of  Layout  Constituents 

The  notation  used  for  the  structure  diagrams  is  that  specified  in 
Appendix  A of  ISO  8613-2. 
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22 ■ 7 . 3 . 2Macro  Definitions 


22 . 7 . 3 ■ 3Factor  Constraints 


FACTOR : ANY- LAYOUT { 

SPECIFIC: 

PERM  Object-type{VIRTUAL) ; 

REQ  Obj ect- identifier {ANY_VALUE ) ; 

REQ  Obj ect-class {VIRTUAL} ; 

REQ  Subordinates (VIRTUAL) ; 

PERM  User-readable-comment {ANY_VALUE) ; 

} 

FACTOR:  ANY- PAGE: ANY- LAYOUT { 

SPECIFIC: 

REQ  Subordinates { SUBORDINATE_ID_OF 
(BasicBody) } ; 

PERM  Obj ect- type ( PAGE ) ; 

PERM  Dimens ions (ANY- VALUE ) ; 

} 


22 ■ 7 . 3 . 4Constituent  Constraints 


22 . 7 . 3 . 4 . ILayDoc : ANY-LAYOUT{ 


SPECIFIC: 

CASE  $DAC  0F{ 
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$FPDA: 

REQ  Object-class {OBJECT_CLASS_ID_OF(LayDoc) ) ; 
REQ  Subordinates { SUBORDINATE_ID_OF(PageSet) } ; 
PERM  Obj  ect- type { DOCUMENT_LAYOUT_ROOT } ; 

} 


22 . 7 . 3 . 4 . 2PageSet : ANY-LAYOUT{ 

SPECIFIC: 

REQ  Object-class{OBJEGT_CIJ^SS_ID_OF(PageSet)  } ; 
REQ  Subordinates{SUBORDINATE_ID_OF(Page)) ; 

PERM  Obj ect- type { PAGE_SET ) ; 

PERM  Application-comments { "PageSet” ) ; 


22.7.3.4. 3 Page : ANY- PAGE { 

SPECIFIC: 

REQ  Object-class{OBJECT_CLASS_ID_OF(Page) } ; 
REQ  Mediiim-type{NON_BASIC)  ; 

PERM  Application- comments { "Page" ) ; 

} 


22.7.3.4. 4BasicBody ; ANY- FRAME { 

SPECIFIC: 

REQ  Ob j ec t - c las s { OBJ ECT_CLAS S ID  OF ( 

BasicBody) } ; 

PERM  Content -port ions {ANY_VALUE) ; 

PERM  Application-comments { "BasicBody" } ; 

PERM  Dimensions {#horizontal{ 

#fixed{ANY_VALUE) ) , 

#vertica.i {#f  ixed{ANY_VALUE)  ) 

}; 

PERM  Presentation- style { STYLE  ID_OF(PStyie3 ) ; 

) 


22.7.4Layout  Style  Constraints 
No  layout  style  constraints  applicable  in  this  clause. 


22 . 7 . SPresentation  Style  Constraints 
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Note:This  section  has  not  been  aligned  with  the  logical  and 
layout  constraint  oblects  defined  in  sections  22.7.2  and 
22.7.3. 

22 . 7 . 5 . IMacro  Definitions 


DEFINE (R- PRES -ATTR, " 

PERM  Pel-path{ ' 0-degrees ' j '90-degrees'); 

PERM  Line-progression{ '270-degrees' ) ; 

PERM  Pel-spacing{ANY_INTEGER  <=1200); 

PERM  Clipping{ANYJ7ALUE} ; ”) 


22 . 7 . 5 ■ 2Factor  Constraints 

FACTOR:  ANY -PRESENTATION -STYLE  { 

REQ  Presentation-style-identif ier { ANY_VALUE) ; 
PERM  User-readable-coraments { ANY__VALUE}  ; 

} 


22 ■ 7 . 5 . 3Constituent  Constraints 


22.7.5.3. lPStyle3 : ANY- PRESENTATION- STYLE { 

REQ  Content -archi tec ture-c las s{$RFP} ; 

PERM  Presentation-attributes{$R-PRES-ATTR} ; 

} 


22 ■ 7 . SContent  Portion  Constraints 


22 . 7 . 6 . IRaster  Graphics  Content  Portion 

DEFINE(T6,'’{2  8 3 7 0}'’) 

DEFINE(BITMAP,'’{2  8 3 7 3}") 

DEFINE(TILED,"{2  8 3 7 5}”) 

PERM  Content-identifier-logical{ANY_VALUE) ; 
PERM  Content-identifier-layout{ANY_VALUE) ; 

PERM  Type-of-coding{$T6  j $BITMAP  i $TILED} ; 
PERM  Coding-attributes! 

#Coiripression{  'Compressed' ) , 

#Nujiiiber  - of  - 1 ines  { A1TY__VALUE } , 

#Nuffiber-of -pels-per- line! ANY_VALUE) , 
#Number-of-pels-per-tile-line !ANY_VALUE) , 
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#Number-of- lines-per- tile { ANY_VALUE} , 
#Tiling-offset{ANY_VALUE) , 
#Tile-types{ANY_VALUE) } ; 

PERM  Content-information{ANY_VALUE} ; 

22 . 7 ■ 7Additional  Usage  Constraints 

No  other  usage  constraints  are  currently  defined. 


22.8  INTERCHANGE  FORMAT 


Interchange  format  class  "A"  is  to  be  used  in  this  application 
profile,  as  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for 
Abstract  Syntax  Notation  One  (ASN.l),  as  defined  in  ISO  8825. 


22.8. lASN . 1 Generation  Constraints 


The  following  are  additional  constraints  imposed  on  the  ASN.l 
generation  beyond  those  defined  in  ISO  8824  and  ISO  8825. 


22 . 8 . 2Encoding  of  Application  Comments 

ISO  8613-5  define  the  encoding  of  the  attribute  Application  Comments 
as  an  octet  string.  This  document  application  profile  requires  that 
the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.l 
syntax  specified  in  the  following  module  definition. 

NISTDAPSpecif ication 

DEFINITION: :=BEGIN 

EXPORTS  Obj ect-Appl-Comm-Encoding; 

Obj ect-Appl-Comm-Encoding: :=SEQUENCE  { 

Constraint-name [0] IMPLICIT  PrintableString 
OPTIONAL, 

External-data[l] EXTERNAL  OPTIONAL  ) 

END 

Note:  There  is  a proposal  to  change  the  External -data  to  allow  for 
any  octet  string. 
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22 ■ 8 ■ 3Encoding  of  Raster  Content  Information 

The  encoding  of  raster  content  information  in  the  bitmap  encoding 
scheme  is  that  specified  in  clause  9.3  of  the  raster  graphics  content 
architecture  part  of  the  base  standard.  The  encoding  of  the  code 
words  in  the  Group  4 facsimile  encoding  scheme  is  such  that  the  first 
or  only  bit  of  the  first  code  word  shall  be  placed  in  the  least 
significant  bit  of  the  first  octet.  Subsequent  bits  of  the  first  and 
following  code  words  are  placed  in  the  direction  of  more  significant 
bits  in  the  first  and  following  octets. 


22,9  GSS/RSS  PROFORMA 


22 ■ 9 . IGenerator  Support  Statement  Proforma 

NoteiThis  section  is  being  written  in  conjunction  with  the 
ODA  document  application  profile  International  alignment 
activity  in.  PAGODA. 


22 . 9 . 2Receiver  Support  Statement  Proforma 

Note:This  section  is  being  written  in  conjunction  with  the 
ODA  document  application  profile  International  alignment 
activity  in  PAGODA. 
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23.  REFERENCES 


Editor's  Note: In  this  document,  references  are  maintained  in 
the  individual  sections  as  appropriate.  Additional  references  for  all 
of  the  subject  covered  in  this  document  may  be  found  in  the  aligned 
references  section  of  the  Stable  Implementation  Agreements  Document, 
Version  3,  Edition  2,  March  1990. 
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